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ABSTRACT 


This  thesis  describes  a  component-based  methodology  for  developing  a  new  class 
of  systems  called  spatial  decision  support  systems  (SDSS).  The  methodology  is 
presented  within  the  context  of  the  development  of  the  ARIES  (Army  Reserve 
Installation  Evaluation  System)  software  application,  an  SDSS  designed  to  evaluate  and 
compare  site  desirability  for  Army  Reserve  unit  locations.  The  ARIES  SDSS  consists  of 
a  flexible  component-based  architecture  that  seamlessly  integrates  a  user  interface,  GIS, 
multi-criteria  decision  model  with  associated  DSS,  and  data  warehouse. 

To  build  the  SDSS,  the  ARIES  developers  introduced  a  new  architectural 
paradigm,  undertaking  a  collaborative  approach  with  U.S.  Army  Reserve  Conunand 
(USARC)  decision-makers  to  rapidly  prototype  ARIES  using  component-based 
technologies.  The  developers  implemented  several  domain-specific  architectures  using  a 
formalized  proof-of-concept  heuristic,  Concept-to-Code  (C2C),  which  conceptualizes 
user  requirements  in  architectural  terms,  and  migrating  legacy  data  sources  into  a  spatial 
data  warehouse. 

C2C  allowed  the  resultant  ARIES  application  to  be  conceptualized  initially  in 
general  terms,  and  then  specialized  architecturally  around  existing  off  the  shelf 
components,  as  design  requirements  were  collaboratively  prototyped  and  implemented 
within  the  existing  USARC  information  system  infrastructure.  C2C  facilitated  the 
complete  development  of  a  complex,  map-based  system  and  accompanying  data 
warehouse  in  the  span  of  a  few  months  with  a  technical  team  of  three  analysts  and 
programmers.  Significant  system  performance  gains  resulted  from  instituting  a  Migration 
Architecture  System  (MARS)  engine  to  extract  and  spatially  enable  relevant  data  sources 
for  geographic  querying.  Additional  performance  enhancements  were  also  obtained 
through  the  use  of  rapid,  component-based  development  techniques. 
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I.  INTRODUCTION. 


“There  is  nothing  more  difficult  to  take  in  hand,  more  perilous  to  conduct,  or 
more  uncertain  in  its  success,  than  to  take  the  lead  in  the  introduction  of  a  new 
order  of  things.  ” 

Niccolo  Machiavelli,  The  Prince,  1532. 

“We  are  living  in  an  information  age  where  almost  everything  is  seen  as 
technically  possible  given  the  commitment  and  the  resources." 

Martyn  Jones, 

“Information:  It’s  Architecture  and  Management”,  1997. 

“We  can  no  longer  afford  stovepiped  systems.  And  it’s  not  just  an  affordability 
issue,  it’s  a  warfighter  issue.  ’’ 

General  Ronald  Griffith,  Vice  Chief  of  Staff  of  the  Army,  1997. 


A.  THESIS  OVERVIEW. 


The  primary  purpose  of  the  research  conducted  for  this  thesis  is  to  investigate  and 
document  the  architectural  approaches  used  in  developing  the  Army  Reserve  Installation 
Evaluation  System  (ARIES)  spatial  decision  support  system  (SDSS)  for  the  United  States 
Army  Reserve  Command  (US ARC).  The  objective  of  ARIES  is  to  automate  the  process 
of  evaluating,  potential  relocation  sites  for  units  of  the  Army  Reserve  from  the  vantage 
point  of  military  readiness. 

Successful  implementation  of  the  ARIES  SDSS  could  greatly  assist  the  Army 
Reserve  in  its  effort  to  ensure  that  a  consistent,  analytical  approach  to  relocating  units  is 
adopted.  Additionally  it  would  also  significantly  reduce  the  time  spent  by  US  ARC 
decision-makers  manually  tracking,  calculating,  and  assessing  the  multiple  criteria 
relevant  to  each  facility’s  site  desirability.  The  use  of  information  technology  (IT)  in  the 
form  of  an  architecturally-driven  prototype  application  can  improve  the  quality, 
timeliness,  and  accuracy  of  the  Army  Reserve  Unit  relocation  decision  specifically,  and 
of  similar  spatially  oriented  decisions  in  general. 
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B.  THE  MOTIVATION  FOR  ARIES. 


The  sponsor  of  this  research  is  the  Force  Support  Package  (FSP)  Readiness 
Office,  a  hierarchical  component  of  USARC  based  in  Atlanta,  Georgia.  This  group  is 
tasked  with  properly  assessing  and  improving  the  military  readiness  of  priority  Troop 
Program  Units  (TPU).  In  the  spring  of  1996,  several  field-grade  officers  of  the  FSP 
approached  the  Naval  Postgraduates  School  (NPS)  building  a  decision  support  system  to 
automate  and  expedite  the  selection  process  for  relocating  Army  Reserve  units.  The 
manual  process  currently  in  use  is  unnecessarily  complex,  unwieldy,  and  limiting  for 
USARC  decision-makers,  and  a  technical  solution  offers  increased  degrees  of  freedom  in 
making  these  crucial  readiness  decisions. 

Under  the  mantra  of  ‘‘‘'Resources  to  Readiness”,  USARC  and  NPS  formed  a 
collaborative  partnership  to  explore  the  concept  of  automated  decision-making  for  site 
location  decisions.  The  research  project  was  undertaken  by  an  NPS  team  of  two 
academic  principal  investigators,  and  three  application  developers.  This  team  identified 
location  as  one  of  the  critical  factors  affecting  unit  readiness,  and  based  upon  this 
assumption,  implemented  a  computer  based  decision  model  to  support  the  unit  relocation. 
A  spatial  decision  support  system  was  used  to  leverage  the  geographic  nature  of  the 
decision  problem. 

C.  OBJECTIVES,  SCOPE,  AND  METHODOLOGY. 

1.  Objectives. 

The  ARIES  application  was  accomplished  by  integrating  a  multi-criteria  Army 
Reserve  imit-decision  model  (ARU-DM),  over  a  dozen  USARC  data  sources  and 
geographic  information  system  (GIS)  into  a  SDSS.  The  SDSS  was  developed  using  rapid 


prototyping  based  upon  a  component-based  development  heuristic,  Concept-to-Code 
(C2C),  and  domain-specific  architectures.  The  design  heuristic  was  used  as  a  structured 
means  to  assist  the  end  users  in  conceiving  the  desired  system,  to  facilitate  development 
of  a  Data  Migration  Warehouse  (DMW),  and  to  enable  the  developers  in  systematically 
engineering  the  SDSS  application  to  fit  within  the  existing  USARC  Headquarters  IT 
infrastructure. 

The  objective  of  this  research  is  to  describe  how  the  C2C  approach  facilitated  the 
development  of  a  complex,  map-based,  multi-criteria  decision  support  system  with  a 
small  team  in  a  matter  of  months. 

2.  Scope. 

This  thesis  addresses  only  the  issues  involved  in  architecturally  developing  and 
implementing  the  ARIES  SDSS  using  component-based  technologies.  For  a  more 
complete  examination  of  the  issues  involved  in  framing  the  Army  Reserve  Unit  Decision 
as  a  Multi-Attribute  Utility  Theory  model,  refer  to  LCDR  Mark  A.  Murphy’s  master’s 
thesis  Automated  Spatial  Decision  Support  System  for  the  Relocation  of  Army 
Reserve  Units’’'  (Murphy,  1997).  Additionally,  the  development  of  the  Data  Migration 
Warehouse  was  spearheaded  by  LCDR  Robert  W.  Dill  and  the  issues  of  data  warehousing 
and  data  quality  are  discussed  in  his  master’s  thesis  “Data  Warehousing  and  Data 
Quality  for  a  Spatial  Decision  Support  System  ”  (Dill,  1 997). 

3.  Methodology. 

The  primary  function  of  the  ARIES  SDSS  is  computation  of  the  twenty  decision 
parameters  identified  in  the  ARU  Decision  Model  from  the  extracts  of  designated  data 
sources  in  accordance  with  elicited  processes  and  user  selections.  USARC  specified  that 
the  ARIES  SDSS  should  access  only  the  existing  Information  Systems  (IS)  infrastructure 
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and  historical  databases  as  the  primary  sources  for  computing  decision  model  parameters. 
This  avoided  the  need  for  additional  data  collection  and  data  normalization.  The  impact 
of  this  constraint  on  the  ideal  model  structure,  derived  from  user  specified  requirements, 
was  carefully  evaluated  and  implemented.  Managed  data  resources  were  properly 
identified  from  those  readily  available  to  USARC.  The  consolidation  of  multiple  sources 
into  an  appropriate  database  schema  for  this  software  application  presented  a  significant 
technical  programming  challenge. 

Due  to  the  limited  availability  of  programming  resources  and  user  specified 
requirements,  the  SDSS  needed  to  integrate  various  commercial  software  tools.  An 
RDBMS  and  a  DSS  were  combined  to  manage  and  manipulate  the  data.  Because  of  the 
spatial  significance  of  many  of  the  variables,  a  GIS  was  also  incorporated  for  both 
displaying,  selecting,  and  manipulating  the  information.  The  proposed  software  system 
contains  five  major  subsystems:  the  ARU  decision  model,  a  single  point  user  interface, 
data  migration  management,  geographic  information  system  (GIS),  and  a  client-server 
architecture  design. 

To  rapidly  accomplish  these  tasks  required  the  development  team  to  concurrently 
innovate  and  integrate  several  technical  disciplines  in  ways  not  previously  envisioned. 
The  final  result  was  a  SDSS  prototype  that  incorporates  the  leading-edge  aspects  of 
spatial  mapping,  geographic  selection,  data  warehousing,  and  decision  support 
technologies. 

Component-based  application  development  based  upon  a  systematic  and 
architecturally-driven  approach  was  used  in  developing  the  ARIES  SDSS  client-server 
architecture.  Rapid  prototyping  techniques  were  also  used  to  conceptualize  the  product 
design  in  accordance  with  user  requirements  and  provide  functionality  for  differing  levels 
of  detail  in  capturing  the  decision  knowledge. 


The  current  version  of  the  ARIES  SDSS  prototype  was  implemented  by  the  NFS 
development  team  using  Microsoft’s  Visual  Basic  for  Applications  (VBA)  programming 
language  with  and  third-party  software  including  Mapinfo  Corporation’s  integrated 
mapping  components,  Mapinfos’  Basic  development  language,  and  the  Logical  Decision 
for  Windows  (LDW)  decision  support  system.  The  SDSS  was  based  on  the  client-server 
computing  model  and  used  the  Microsoft  OLE  2.0  commxmication  protocol  as  the 
primary  means  of  component  communication. 

D.  ORGANIZATION  OF  THESIS. 


This  thesis  contains  useful  information  on  building  applications  using  component- 
based  development  from  a  software  architectural  point  of  view.  It  should  be  particularly 
valuable  to  decision-makers,  information  system  architects,  computer  programmers,  and 
data  managers.  The  balance  of  this  study  is  structured  into  several  modules  and 
organized  as  described  below: 

•  Chapter  II  -  Opens  with  a  futuristic  scenario  description  about  potential  uses 
for  next  generation  ^EXGEN)  versions  of  ARIES.  Additionally,  a 
background  discussion  is  provided  about  the  LfSARC  organization,  their  need 
for  a  SDSS  and  an  overview  of  the  intended  system. 

•  Chapter  III  -  Discusses  the  benefits  of  using  component-based  development 
in  conjvmction  with  a  new  software  architectural  paradigm  (Architectonic) 
through  the  use  of  a  design  heuristic  (Concept-to-Code).  This  chapter  closes 
by  describing  the  ARIES  SDSS  creation  using  the  design  heuristic. 

•  Chapter  IV  -  Discusses  the  lessons  learned  from  using  component-based 
development  and  rapid  prototyping  when  developing  complex  spatial 
applications  using  existing  infrastructure. 

•  Chapter  V  —  Provides  future  recommendations  for  further  study  and  presents 
the  conclusions  of  this  thesis  study. 
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II.  BACKGROUND. 


''‘'Nothing  is  Built  unless  it  is  Imagined  First.  ” 

NRaD  “Command  Center  of  the  Future”  Motto. 

“Our  ability  to  imagine  complex  applications  will  always  exceed  our  ability  to 
develop  them.  ”  Grady  Booch,  Object  Solutions,  1996. 

“The  hardest  single  part  of  building  a  software  system  is  deciding  precisely  what 
to  build.'^  Fred  Brooks,  “No  Silver  Bullet”,  1987. 

A.  FUTURE  SCENARIO. 

1158  HRS:  Colonel  Jackson  R.  McMurdo,  Army  liaison  to  the  newly  formed 
BRAC  Commission  2000  on  active  and  reserve  Army  unit  basing  matters,  was  looking 
forward  to  devouring  his  pastrami  on  rye  when  the  phone  rang  xmceremoniously.  He 
answered  impatiently  and  immediately  recognized  the  frantic  voice  of  Randolph  Braid, 
Senator  Jeremiad  Beamegard’s  BRAC  aide.  McMurdo  knew  the  drill  without  hearing 
another  word.  As  the  BRAC  chairman,  the  senior  Senator  from  the  Southeast  was  taking 
considerable  heat  from  the  Senate  Armed  Services  Committee  about  closing  bases  V,  X, 
Y,  Z,  and  corresponding  Army  unit  relocation.  An  alternative  plan  consisting  of  only 
closing  bases  X,  Z,  and  adding  bases  W  and  U  had  been  suggested  by  the  Committee, 
wherein  the  displaced  Army  units  would  be  relocated  to  base  Y.  This  was  an 
unanticipated  scenario  based  on  previous  assumptions  and  findings,  and  the  Senator 
would  need  this  counter-proposal  analyzed  before  reconvening  within  the  hour,  or  the 
whole  BRAC  list  could  lose  the  full  support  and  recommendation  of  the  Armed  Services 
Committee. 

“How  does  it  look  if  we  keep  open  bases  V  and  Y  and  close  bases  U,  W,  X,  and 
Z?”  Braid  asked  breathlessly. 
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“Off  the  top  of  my  head  it  appears  to  be  a  viable  alternative,  but  I’ll  have  to  run  it 
through  the  SDSS  to  be  certain.”  McMurdo  disliked  these  incessant  fire  drills  from 
Congress  and  let  his  pique  slip  ever  so  lightly  into  his  tone. 

“Jack,  Ave  need  you  to  disregard  the  condition  of  the  equipment  and  facility  age, 
and  focus  instead  on  civilian  employment  and  impact  on  the  community  at  large  if  those 
bases  are  closed  and  their  units  relocated.” 

“Consider  it  done.  Just  ensure  the  Senator’s  NetPC  PointCast  is  set  to  receive 
multi-broadcast  material  and  the  multimedia  presenter  is  in  automatic  mode.” 

“Understand.  Thanks  Jack,”  said  Braid  contritely,  hanging  up  his  cellular  phone. 

1206  HRS:  Turning  in  his  chair  while  setting  his  lunch  aside.  Colonel  McMurdo 
stoically  started  his  wireless  laptop  and  logged  into  the  Pentagon’s  DoD  Intranet. 
Accessing  the  U.S.  Army  website,  he  launched  the  ''ARGIS  2/”  applet  and  began 
configuring  the  network  user  interface  (NUI)  for  the  appropriate  mapping  component  and 
DSS  model  preferences. 

He  then  entered  the  Dept  of  the  Army  Data  Warehouse  and  chose  the  applicable 
DataMarts  and  databases  on  military  leadership,  readiness,  competition,  and  status-of- 
forces  to  be  integrated  with  the  OMB  Economic/Financial  databases  and  U.S.  Census 
Bureau  City/State  DataWarehouse. 

1209  HRS:  Selecting  the  “Build  Scenario”  function,  the  ARGIS  DataMigrator 
began  extracting  and  conditioning  the  desired  data  to  a  disposable  database  on  a  remote 
RDBMS  server.  Simultaneously,  the  ARGIS  Dataintegrator  began  creating  various 
communication  links  to  the  BRAC  decision  model,  spatial  mapping  components,  and  the 
new  BRAC  DataDepot. 

1217  HRS:  Colonel  McMurdo  graphically  chose  the  Army  units  and  bases  to  be 
evaluated  and  executed  the  scenario  analysis.  Using  remote  automation  workflow 
technology,  the  process  co-opted  idle  network  processors  to  achieve  a  standard  solution 


in  two  minutes.  From  this  baseline  the  Colonel  reduced  the  weighting  on  facility  age  and 
condition  whiling  increasing  civilian  employment  valuations.  He  did  not  like  what  he 
saw. 

1221  HRS:  Defining  a  300  mile  radius  “what-if  ’  circular  analysis  polygon  around 
the  target  site,  the  Colonel  redirected  the  ARGIS  AI-Analyzer  to  determine  which  units 
must  be  moved  to  the  target  site  of  interest  to  achieve  the  desired  outcomes.  ARGIS 
reverse  engineered  the  spatial  environment  and  recommended  several  courses  of  action 
and  budgetary  schedules  to  achieve  the  objective  over  the  course  of  the  base  closing 
timeline.  This  looked  much  better.  McMurdo  recognized  the  resultant  solution  as  one 
minimizing  the  economical  impact  to  a  thriving  community.  He  reviewed  and  selected 
the  analysis  summaries  that  respectively  best  supported  and  contradicted  the  Committee’s 
argument . 

1232  HRS:  Using  the  ARGIS  Animator,  he  converted  the  analysis  to  a  data 
visualization  movie  displaying  the  best  solution  with  different  color-coded  alternatives 
over  time  as  bases  closed  and  units  relocated.  He  graphed  the  economic  impact 
thematically  per  site  over  time  and  marveled  at  the  efficiency  of  the  system. 

1244  HRS:  The  telephone  rang  again.  It  was  Braid  once  more.  “Jack,  the 
committee’s  reconvening  early!  What  have  you  got?  We  have  to  tell  them  something.” 

“No  problem,  I  have  just  broadcast  the  textual  analysis  to  Beauregard’s  NetPC  on 
the  Senate  floor  and  the  ARGIS  Solution  should  be  playing  on  the  large-screen  display  as 
we  speak.”  McMurdo  was  calm  and  amused  as  he  noted  the  contrast  of  his  demeanor 
with  Braid’s  anxiety. 

“Thanks  Jack,”  said  Randolph.  “You  saved  our  bacon  on  this  one.” 

1701  HRS:  Jack  timed  his  computer  into  the  Inet-CNN  broadcast  and  allowed 
himself  a  small  nod  of  satisfaction  to  see  the  lead  story  was  about  a  remarkable 
breakthrough  in  the  BRAG  closure  plan  impasse.  As  newscast  switched  to  the  ARGIS 
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animation  film,  a  voice-over  announced  in  serious  tones,  “In  a  dramatic  eleventh  hour 
move,  a  compromise  was  reached  in  the  Senate  today.” 

As  he  watched  the  screen,  his  mind  lamented  about  his  previous  assignment  to 
US  ARC  Headquarters  so  many  years  ago.  Catching  himself  smiling.  Jack  spoke  aloud, 
“Who  would  have  thought  the  progeny  of  the  ARIES  project  would  have  been  so. . . . 

B.  USARC  AND  READINESS. 

The  previous  scenario  may  seem  like  a  work  of  science  fiction,  but  given  the 
continued  proliferation  of  information-based  technologies,  this  future  may  be  a  lot  closer 
than  we  think.  Until  a  year  ago,  if  the  United  States  Army  Reserve  Center  (USARC) 
needed  to  move  a  reserve  unit,  the  analysis  to  manually  evaluate  several  alternatives 
required  a  Herculean  effort  on  the  part  of  the  Army  analysts.  The  proposed  site  selection 
process  could  take  up  to  30-40  days  to  develop  just  a  partial  solution.  This  was  due  to  the 
complexity  of  the  decision,  multiple  disparate  data  sources,  quantifying  subjective 
judgments,  and  analyzing  approximately  1300  possible  alternatives.  Today,  with  the 
successful  partnership  between  USARC  and  the  Naval  Postgraduate  School  (NPS),  the 
same  analysis  can  be  completed  in  minutes  using  a  deployed  stand-alone  Spatial  Decision 
Support  System  (SDSS)  called  ARIES,  that  shares  many  similar  concepts  to  ARGIS  21, 
only  in  a  more  primitive  and  prototypical  form.  The  ARIES  concept  consists  of  a 
delivery  portion  and  a  data  and  applications  portion.  The  delivery  system  includes  COTS 
hardware  and  software  that  provides  workflow  automation  by  calculating  design  model 
parameters.  The  data  and  application  software  satisfied  the  functional  requirements  for 
maintaining  the  data  sources,  automating  business  processes,  and  interfacing  with  the 
decision-makers. 

The  purpose  of  this  research  is  to  increase  readiness  using  Information 
Technology  (IT)  in  a  manner  that  will  dramatically  improve  the  process  used  to  select 
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relocation  sites  for  Army  Reserve  Units.  The  final  outcome  is  a  repeatable  and  accurate 
process  whose  cycle  time  collapses  from  40  days  to  an  average  of  eight  minutes  per  site 
selection  scenario. 

These  order-of-magnitude  improvements  in  analysis  capability  can  be  directly 
linked  to  the  decentralized  improvement  in  IT  practices  from  host-based  computing 
(mainframes)  to  a  distributed,  network-centric  computing  environment.  Computing 
environments  that  previously  were  relatively  simple  have  exploded  into  a  plethora  of 
networks,  clients,  servers,  and  component-oriented  systems.  Computing  complexity  has 
skyrocketed  and  with  it  the  future  potential  for  greater  usage.  Technological  choices, 
although  daunting,  have  now  begun  to  take  into  consideration  the  issues  of  scalability, 
extensibility,  and  an  increasingly  uncertain  future.  Technological  solutions  are  becoming 
the  means  to  effectively  and  efficiently  increase  military  readiness. 

At  the  1994  Software  Technology  Conference  in  Salt  Lake  City,  Utah,  the 
Honorable  Emmett  Paige,  Assistant  Secretary  of  Defense  for  C3I  illustrated  the  strong 
interdependence  that  exists  between  information  technology  and  ihilitary  readiness  in  his 
keynote  address: 

Software  drives  Military  Readiness.  As  such,  our  military  state  of 
readiness  is  changing  to  support  fighting  and  winning  two  major  regional 
conflicts  at  the  same  time.  As  the  world  situation  changes,  it  becomes 
increasingly  the  case  that  we  will  have  to  project  our  military  capability 
with  less  notice  and  more  precise  results.  The  Secretary  of  Defense  has 
made  it  clear  that  our  highest  priority  must  be  readiness.  We  must  get  om 
software  act  together... and  provide  the  support  that  our  war  fighters  need, 
wherever  they  are,  no  matter  how  short  a  notice.  And  we  must  proceed 
with  a  sense  of  urgency  in  making  our  software  become  predictable,  in  the 
sense  of  its  high  quality  and  high  contribution  to  the  defense  mission. 

(Paige,  1994) 

This  situation  presently  confronts  all  military  commands,  and  the  work  described 
in  this  thesis  takes  a  useful  step  forward  in  answering  the  challenge  of  increased  readiness 
for  the  U.  S.  Army  Reserve  Command. 
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1.  United  States  Army  Reserve  Command. 


Public  Law  101-510,  the  Defense  Authorization  Bill  of  November  5,  1990, 
provided  for  the  establishment  of  a  U.  S.  Army  Reserve  Command  imder  the  command  of 
the  Chief  of  Army  Reserve  (Figure  2-1).  “Since  the  completed  transition  on  September 
30,  1992,  the  US  ARC  has  assumed  peacetime  command  and  control  of  all  United  States 
Army  Reserve  forces,  except  for  Special  Operations  elements  and  United  States  Army 
Reserve  forces  located  outside  of  the  continental  United  States”  (DOD IG,  1993,  p.  12). 

The  Department  of  Defense’s  1993  Inspector  General,  described  the  US  ARC 
mission  objectives  as  follows: 

•  “Command,  control,  support,  and  ensure  wartime  readiness  of  the  U.S.  Army 
Reserve  Forces. 

•  Organize,  train,  and  prepare  U.  S.  Army  Reserve  units  for  mobilization  and 
commitment  to  a  wartime  theater  of  operations. 

•  Manage  and  execute  all  Operations  and  Maintenanee,  Army  Reserve  (OMAR) 
and  Reserve  Personnel,  Army  (RPA)  funds  allocated  by  Headquarters, 
Department  of  the  Army. 

•  Support  mobilization  as  directed  by  FORSCOM.”  (DOD  IG,  1993,  p.  14) 

In  order  to  eomply  with  these  aseribed  functions,  US  ARC  “...decision-makers 
must  be  able  to  effectively  manage  the  resourees  supporting  readiness  and  mobilization 
preparedness”  (DOD  IG,  1996,  p.  22). 

The  capability  to  accomplish  this  goal  is  directly  related  to  the 
management  and  availability  of  information.  The  existing... Army  Reserve 
information  systems  are  imable  to  provide  timely  and  accurate  information 
to  decision-makers  to... [enable  either  unit  relocation  or]  mobilization 
planning...as  required  to  meet  contingency  plans.  (DOD  IG,  1996,  p.  22) 

The  Army  Reserve  Command  must  often  manually  compile 
information  requested  by  eommanders  and  higher  headquarters. 
Additionally  updating  information  is  time  and  manpower  intensive  and, 
therefore,  is  often  not  done  as  frequently  as  needed.  (DOD  IG,  1996,  p. 

23) 
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Figure  2-1.  U.S.  Army  Reserve  Management  Structure. 
After  (DOD IG,  1993,  p.  13) 
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With  the  1994  Department  of  Defense  stipulation  to  buy  Commercial  Off-The- 
Shelf  (COTS)  technology  whenever  possible,  USARC  is  currently  migrating  its 
information  systems  and  networks  from  legacy  applications  and  databases  to  well- 
supported  commercial  software  suites  running  Microsoft  Windows  95  and  NT-based 
environments. 

Because  of  the  huge  expense  of  maintaining  and  operating  legacy  information 
systems,  limited  resomces  are  available  for  new  application  development.  Failure  to 
think  strategically  about  software  development  has  lead  to  the  formation  of  many  stove- 
piped  applications  and  “data  silos  of  information.”  In  order  to  counteract  this  downward 
spiral,  the  high  costs  of  these  systems  must  be  effectively  leveraged  using  commercial 
technology.  Instead  of  deploying  systems  that  meet  USARC’s  short-term  needs,  USARC 
needs  to  develop  applications  capable  of  change  and  of  evolving  with  changing  business 
processes. 

In  response  to  this  challenge,  USARC  established  a  partnership  with  the  Naval 
Postgraduate  School  to  develop  an  Army  Reserve  Unit  Decision  Model  (ARU-DM)  and 
SDSS  prototype  to  automate  the  site  relocation  analysis  of  existing  reserve 
facilities/units. 


2.  Readiness  Issue. 


The  sponsor  of  this  research  is  the  Force  Support  Package  (FSP) 
Readiness  Office,  a  recently  formulated  component  of  the  U.S.  Army 
Reserve  Command.  This  group  is  tasked  with  assessing  and  improving 
the  readiness  of  priority  Troop  Program  Units  (TPU)  across  the  country. 

A  TPU  is  the  basic  building  block  of  the  Army  Reserve  force,  typically 
consisting  of  about  150  reservists.  The  TPU’s  tiiat  are  of  most  concern  to 
the  Readiness  Office  are  in  the  FSP,  which  are  the  units  designated  for 
rapid  deployment.  (Murphy,  1997,  p.  1) 

Military  readiness  can  be  classified  into  two  types,  operational  and  structural, 
which  differ  in  granularity  (Betts,  1995).  Operational  Readiness  deals  with  status  of 
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individual  units  whereas  Structural  Readiness  deals  with  the  overall  force  structure  in  the 
sense  of  “how  soon  a  force  of  the  size  necessary  to  deal  with  the  enemy  can  be  available” 
(Betts,  1995).  The  focus  of  this  research  is  on  the  operational  readiness  of  those  Army 
Reserve  units  scheduled  for  rapid  deployment.  In  this  context,  readiness  primarily  refers 
to  persoimel  readiness,  the  ability  to  maintain  enough  properly  trained  and  qualified 
people. 

The  statistics  chosen  by  US  ARC  decision-makers  to  fimction  as  the  primary 
indicators  of  unit  operational  readiness  are  Fill  Level,  MOS  Qualification  Level,  and 
Turnover  Rate.  The  high  persoimel  turnover  rates  recently  suffered  by  the  USAR  have 
significantly  reduced  readiness.  With  the  average  retraining  period  lasting  nine  to  ten 
months,  between  20  and  30  percent  of  the  required  positions  are  routinely  filled  by 
imqualified,  non-deployable  individuals  (Murphy,  1997,  p.l3).  Although  Military 
Occupational  Specialty  (MOS)  qualifications  are  not  always  a  direct  measure  of 
warfighting  capabilities,  unqualified  individuals  directly  diminish  the  number  of  soldiers 
available  to  supplement  active  forces. 

Performance  in  these  areas  can  be  related  to  numerous  location-dependent  factors, 
ranging  from  access  to  preferred  recmiting  markets  and  distances  to  various  training 
support  sites.  The  most  significant  location  related  factor  is  the  recruiting  market;  for 
unlike  the  active  services,  reserve  units  must  recruit  exclusively  from  the  local 
population.  When  a  imit  is  stmggling  to  maintain  personal  readiness,  sometimes  the  best 
solution  is  unit  relocation.  This  thesis  is  based  on  the  “...premise  that,  holding  all  other 
readiness  variables  constant,  it  is  possible  to  improve  the  operational  readiness  of  some 
Army  Reserve  units  by  relocating  them  to  preferred  areas  as  indicated  by  a  variety  of 
location-related  attributes”  (Murphy,  1997,  p.l3). 
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3.  Army  Reserve  Unit  Decision  Model  (ARU-DM). 


Before  the  creation  of  a  manageable  model  could  proceed,  it  was  necessary  to 

clearly  define  the  TPU  relocation  problem. 

Although  USARC  representatives  suggested  a  variety  of  ways  in  which  to 
understand  the  importance  of  unit  location  (e.g.,  distances,  market 
supportability  areas,  overlap  between  vmits,  etc.),  it  quickly  became  clear 
that  the  primary  objective  was  to  relate  location  to  unit  readiness.  The 
decision  was  made  to  develop  a  [decision]  model  that  could  isolate  and 
evaluate  the  location  sensitive  portion  of  the  unit  readiness  problem. 
(Murphy,  1997,  pp.  19-20) 

“Our  methodology  was  to  interview  the  USARC  experts  to  determine: 

•  A  goals  hierarchy  consisting  of  intermediate  goals  and  decision  parameters, 

•  Tradeoff  fimctions  for  each  parameter  in  the  goals  hierarchy,  and 

•  [Identify  the  appropriate]  weights  for  each  of  the  parameters.”  (Dolk,  et.  al., 
1996). 

Based  upon  the  concerns  and  priorities  of  the  USARC  experts,  the  NFS 
development  team  decomposed  the  overall  objective  of  Site  Desirability  into  twenty 
measurable  decision  parameters.  These  parameters  were  identified  as  objective, 
measurable  attributes  of  a  desired  site  location  and  loosely  grouped  together  in  three 
categories:  People,  Places,  and  Things  (Table  I). 


PEOPLE 

Competition 

Area  Drill  Attendance 

Area  Loss  Rate 

Area  Transfer  Rate 

Average  Area  Manning 

Closing  Unit  Transfers 

IRR  Available 

Recruit  Market 

Reassignments 

Places 

Facility  Age 

Facility  Backlogged  Maintenance 

Facility  Condition  (RED  /  AMBER  /  GREEN) 
Facility  Operating  Costs 

Facility  Government  Owned  (Y/N) 
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Facility  Weekend  Usage 

THINGS 

Distance  to  Recruiter 

Distance  to  AMSA 

Distance  to  ECS 

Available  MOS  Closing 

Available  MOS  IRR 

Table  I.  Army  Reserve  Unit  Decision  Model  (ARU-DM). 
a.  General  Assumptions 


Although  this  modeling  effort  “...does  not  provide  a  rigorous,  causal 
model  of  readiness,  it  is  assumed  that  the  hierarchy  of  screening  factors  provides  a 
meaningful  assessment  of  the  propensity  of  a  given  location  to  support  the  achievement 
of  high  levels  of  readiness”  (Murphy,  1997,  p.31).  For  the  ARU  decision  model,  the 
expert  panel  assumed  that  the  basis  for  evaluation  would  be  a  single  reserve  imit.  One 
alternative  to  this,  relocating  a  portion  or  derivative  of  a  unit,  may  sometimes  be  more 
appropriate,  but  this  was  not  considered  in  the  decision  model.  Secondly,  derived  reserve 
unit  metrics  had  to  be  calculated  directly  from  data  sources  available  on  the  US  ARC  local 
area  network  which  would  be  implemented  in  the  final  application.  Lastly,  the  “area  of 
the  proposed  site”  refers  to  the  region  within  50  miles  of  the  zip  code  centroid  center  in 
which  the  proposed  site  is  located. 

This  proposed  location  will  have  little  or  no  influence  on  where  people 
chose  to  live.  People  will  not  move  just  to  be  closer  to  the  unit  or  relocate 
when  the  unit  does.  (Murphy,  1997,  p.  30) 

b.  Goals  Hierarchy 

Using  the  identified  decision  parameters,  the  ARU  relocation  decision  was 
structured  into  a  goals  hierarchy  using  Multi-Attribute  Utility  Theory  (Figure  2-2). 
Location  data  are  extracted  and  conditioned  from  USARC’s  corporate  data  sources  and 


Figure  2-2.  ARU  Decision  Model  Hierarchy  of  Goals.  Each  component  of  the 
hierarchy  is  organized  by  its  type  (goal,  subgoal,  or  parameter)  and  identified  by  the 
hierarchical  level  at  which  it  exists.  Within  each  section,  components  are  listed 
alphabetically  and  levels  are  ordered  from  top  to  bottom.  After  (Murphy,  1997) 
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converted  to  common  units  of  reference  using  twenty  different  utility  function  curves. 
There  was  one  utility  curve  developed  for  each  decision  parameter.  The  outputs  of  these 
utility  functions  are  repeatedly  combined,  based  on  the  hierarchical  structure  of  the  ARU- 
DM  and  the  relative  weights  elicited  from  the  experts,  to  produce  the  overall  scores  used 
to  rank  the  alternative  sites. 

c.  DSS  Software  Component 

The  COTS  software  package  selected  by  the  NPS  Development  Team  for 
implementing  the  ARU-DM  was  Logical  Decisions  for  Windows  (LDW).  It  was  chosen 
as  the  DSS  software  component  “...primarily  because  it  supports  explicit  specification  of 
tradeoff  functions  for  each  parameter  as  well  as  five  different  decision  analysis 
techniques,  both  quantitative  and  qualitative”  (Dolk,  et.  al.,  1996). 

4.  USARC  Source  Data. 

The  SDSS  prototype  was  originally  implemented  as  a  stand-alone  Windows  95 
version  but  is  currently  operating  in  a  Windows  NT  environment  on  the  USARC 
Headquarters’  Local  Area  Network  (LAN).  One  of  the  stipulated  pretexts  of  the 
prototype  was  that  the  databases  currently  present  on  the  USARC  LAN  are  the  only  data 
sources  eligible  for  deriving  ARU-DM  parameters.  The  primary  reason  for  diis  is  that 
USARC  wanted  to  be  able  to  deploy  the  SDSS  application  without  having  to  shift  the 
burden  of  administratively  supporting  it  to  the  USARC  IS  Staff. 

The  native  data  sources  are  composed  of  a  multitude  of  large  multi-vendor 
databases  (Table  II).  These  databases  are  mostly  flat  file  structures  that  were  haphazardly 
instituted  to  support  several  independent  USARC  applications  as  they  were  deployed  on 
the  LAN.  Some  of  the  files  are  ad  hoc  derivatives  of  larger  off-site  mainfi-ame-based 
databases,  periodically  updated  from  USAR  Headquarters  in  Washington,  D.C. 
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Ownership  and  maintenance  of  the  local  data  sources  is  distributed  amongst  the  primary 
user  base  of  the  stove-piped  applications  (Appendix  A).  Additionally,  there  is  no 
centralized  data  dictionary  or  repository  maintained  for  the  data  sources  or  the  metadata 
that  constructs  them.  Consequently,  there  is  little  consistency  between  the  data  source’s 
design,  structure,  format,  or  key  index  fields.  Database  field  names  are  different  for 
similar  data  sets,  and  most  of  the  files  contain  incomplete,  inaccurate,  and  missing  data. 
This  complete  lack  of  common  institutional  data  standards  greatly  complicated  the 
development  of  an  integrated  data  framework  for  the  SDSS  prototype  (Figure  2-3).  To 
compensate  for  this  unexpected  lack  of  data  quality  and  to  provide  a  stable  baseline 
database  for  deriving  the  decision  parameters,  the  development  team  was  compelled  to 


1  FILENAME 

SOURCE 

TYPE 

LAST 

UPDATE 

FILE  SIZE 

No.  RECORDS 
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HiSQySEMi 
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HSIESiUSlEfli 
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Table  II.  Source  Data  Tables. 


concurrently  design  and  implement  a  Migration  Architecture  System  (MARS)  engine, 
and  a  data  migration  warehouse  (DMW)  variant  —  DataDepot  (Figure  2-4). 
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Figure  2-3.  SDSS  Disparate  Data  Sources  Flow  Diagram 


Figure  2-4.  SDSS  Migrated  Information  Flow  Diagram 
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5.  Information  Systems  Challenge. 


Because  the  entire  TPU  relocation  decision  incorporates  such  a  large  number  of 
parameters,  it  is  nearly  impossible  for  an  unaided  human  decision-maker  to  fully  consider 
all  relevant  factors.  In  the  past  these  decisions  were  typically  based  upon  a  combination 
of  intuition  and  experience,  but  this  ad  hoc  process  was  often  difficult  to  build  a 
consensus  for,  communicate,  and  defend. 

Frustrated  with  the  inadequacies  of  the  approach  to  such  a  complicated  problem, 
the  large  number  of  characteristics  per  facility,  the  number  of  analyses  required,  and  over 
1300  facilities  to  evaluate,  the  Army  Reserve  believed  it  could  deliver 
morecomprehensive  relocation  decisions  by  applying  a  Geographic  Information  System 
(GIS)  and  decision-support  technology  to  the  relocation  decision  process.  In  addition  the 
decision  support  technology  had  to  allow  the  USARC  decision-maker  to  perform  a 
variety  of  ad  hoc  analyses  of  multiple  readiness  factors  to  ensure  that  the  relocation 
recommendation  was  truly  warranted  and  was  in  the  best  interest  of  the  moving  unit. 
This  was  the  inspiration  for  a  fully  automated  software  application  that  could  select, 
calculate,  and  deliver  spatially-oriented  decision  data  to  the  ARU  Decision  Model.  This 
visionary  aspect  of  the  NFS  Initiative,  “A  Geographic  Information  System  Approach  to 
USAR  Unit  Readiness,”  inspired  the  development  of  just  such  an  application  —  the 
Army  Reserve  Installation  Evaluation  System  (ARIES). 

In  order  to  minimize  application  development  time  and  maximize  previous 
USARC  computing  investments,  it  was  important  that  the  automated  ARIES  system 
utilize  the  USARC  IS  infrastructure,  COTS  applications,  and  historical  databases  as  the 
primary  components  for  computing  the  decision  model  factors  (Figure  2-5). 
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Figure  2-5.  ARIES  Conceptual  Infrastructure  Diagram. 


Additionally,  the  NFS  development  team  also  wanted  to  prevent  the  construction 
and  deployment  of  yet  another  requirements-driven  stove-piped  application  (Figure  2-6), 
instead  building  one  that  was  architecturally-driven  (Figure  2-7).  By  this  I  mean  an 
application  in  which  the  specific  requirements  are  traceable,  the  architecture  is  not 
resistant  to  change,  and  the  coding  is  kept  to  minimum  by  leveraging  the  existing 
software  infrastructure.  This  is  the  real  challenge  of  developing  the  USARC  SDSS 
application. 

To  accomplish  this  requires  a  fiondamental  shift  in  the  way  developers  think  about 
and  design  integrated  software  applications.  Instead  of  focusing  on  the  problem  as  “a 
simple  matter  of  programming,”  the  development  team  would  focus  on  the  problem  as  a 
complex  systemic  concept  with  interdependent  resources  and  corresponding  rule-based 
processes.  To  manage  this  approach  effectively  requires  a  new  rational  design  process  — 
the  process  is  partially  proof-of-concept  exploitable,  fully  component-oriented,  and 
architecturally  refinable. 
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COMMON  INFRASTRUCTURE 


Figure  2-6.  The  Structure  of  Requirements-Driven  Projects. 
After  (Booch,  1996,  p.  15) 


In  the  next  chapter  we  will  investigate  the  reasons  for  focusing  our  development 
efforts  on  architectural  design  and  implementation,  develop  a  component-based  heuristic 
that  incorporates  architecturally-driven  concepts,  and  specifically  discuss  the  application 
development  and  implementation  issues  that  went  into  designing  and  building  the  ARIES 
SDSS  prototype. 


Figure  2-7.  An  Architectoe-Driven  System. 
After  (Booch,  1996,  p.  52) 
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III.  ARIES  APPLICATION  DEVELOPMENT. 


“He  who  does  not  lay  his  foundations  beforehand  may  by  great  abilities  do  so 
afterwards,  although  with  great  trouble  to  the  architect  and  danger  to  the 
building.”  Niccolo  Machiavelli,  The  Prince,  1532. 

“New  information  technologies  gradually  give  birth  to  new  activities,  processes, 
and  products.  ”  John  Naisbitt,  Megatrends,  1982. 

“By  1999,  component  software  will  be  the  dominant  method  of  new  application 
development  (0. 7  probabilityf'  Roy  Schulte,  Gartner  Group. 


A.  INTRODUCTION. 

There  is  no  single  product,  book,  management  style,  or  “silver  bullet”  that 
magically  leads  the  developer  or  development  team  through  a  painless  application 
development  process.  “But  a  sensible  use  of  productive  complementary  tools  and 
techniques,  and  a  shift  to  a  paradigm  with  proven  advantages  can  over  time  yield  the 
desired  results”  (Tkach,  1996,  p.  xiii).  In  the  absence  of  any  singular  solution,  the  ARIES 
project  used  a  “proof-of-concept”  heuristic,  Concept-to-Code  (C2C),  to  guide  the 
development  team.  C2C  provided  the  structural  perspective  needed  to  manage  USARC’s 
requirements  and  the  implementation  of  the  decision  model  into  a  cohesive,  integrated 
prototype  using  various  COTS  products,  a  fourth-generation  language,  and  existing 
infrastructure. 

This  chapter  begins  with  an  overview  of  component-based  development  and  the 
new  computing  paradigm  shift  it  ushers  forth.  Next  is  a  discussion  of  the  generic 
requirements  of  each  of  the  C2C  phases,  stages,  and  artifacts,  and  the  corresponding 
ARIES  implementation.  The  final  major  section  is  a  summary  of  the  ARIES 
implementation  using  the  C2C  heuristic  process. 
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B.  BACKGROUND. 


1.  Software  Development:  A  Brief  History  Lesson. 


Prior  to  the  1990’s,  software  development  consisted  primarily  of  programmers 

and  developers  using  conventional  software  development  models  (waterfall,  incremental, 

spiral)  to  build  applications  with  procedural  techniques.  The  majority  of  these 

approaches  involved  the  systematic  use  of  five  basic  steps:  analysis,  design, 

implementation,  testing,  and  maintenance.  This  was  usually  sufficient  as  long  as  the 

users’  requirements  were  clearly  defined,  system  architectures  were  understood, 

complexity  was  low,  and  product  delivery  cycle  was  measured  in  years. 

One  problem  with  the  conventional  ‘waterfall’  software  development 
process  is  that  in  some  situations  it  may  not  be  possible  to  define  the 
software  requirements  fully  at  the  beginning  of  the  software  development 
effort.  Another  problem  is  that  there  may  be  a  significant  risk  that  the 
design  approach  created  to  satisfy  the  requirements  may  be  inadequate.  A 
final  problem  is  that  the  user  only  receives  the  software  at  the  end  of  the 
complete  and  lengthy  process;  the  user  may  need  this  capability  at  an 
earlier  time.  (USAF-STSC,  1992,  p.  15). 

Conventional  software  practices  exploited  “...the  idea  that  if  developers  can  get  perfect 
specifications  up  front,  the  end  result  will  be  a  perfect  application”  (Whitten  et.  al.,  1994). 
Today  this  not  the  case.  As  computing  power  and  user  capabilities  have  increased  with 

technological  change,  the  following  phenomena  transpired: 

•  The  application  development  process  has  become  more  complex  today  than  a 
decade  ago  (Tkach,  1996,  p.  17). 

•  “Line-at-a-time  programming  is.. .increasingly  being  replaced  by  point-and- 
click  visual  development  environments”  (Sama  and  Febish,  1996,  p.  27). 

•  “Interactive  GUI,  distributed... processing,  very  large  integrated... databases 
[and]  heterogeneous  environments....”  have  become  the  norm.  (Tkach,  1996, 
p.  17). 
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Additionally,  most  users  have  become  accustomed  to  a  window-oriented  user 
interface  (U/I),  and  subsequent  interface  expectations  have  risen  accordingly.  The 
application  development  process  “...has  evolved  to  the  point  that  it’s  becoming  entirely 
GUI-based  and  built  up  from  components  using  techniques  of  rapid  application 
development”  (Sarna  and  Febish,  1996,  p.  27).  Complex  GUIs  are  becoming  standard 
requirements  that  are  not  easily  accomplished  with  current  techniques.  The  software 
development  methods  of  the  past  are  insufficient  to  develop  rapidly  the  scalable, 
extensible,  and  flexible  applications  demanded  by  organizations  today.  Speed  of  delivery 
and  completeness  of  stated  requirements  are  the  mantra  driving  the  “solution  du  jour.” 

Currently,  organizations  want  software  development  to  take  into  account  the 
hundreds  of  millions  of  dollars  invested  in  building  IT  infrastmcture,  computing  capacity, 
and  the  resultant  morass  of  accumulated  data.  The  “waterfall”  models  have  failed  to 
provide  the  “silver  bullet”  solution  to  application  development  in  today’s  “Buy-It  versus 
Build-It”  mentality.  In  turn,  they  have  become  the  legacy  methodologies  of  the  same 
legacy  data,  applications,  and  systems  they  helped  to  create.  A  better  solution  needs  to  be 
found.  One  answer  lies  in  the  increasing  popularity  of  component-oriented  computing; 
with  the  continued  maturation  of  the  software  industry,  component-based  development  is 
now  seen  “as  an  important  step  toward  the  industrialization  of  software  that  can  help  to 
transform  programming  from  an  arcane  craft  to  a  systematic... process”  (Taylor,  1991,  p. 
iii). 

2.  Component-Based  Revolution 

Component-based  development,  the  ability  to  design  and  build  fi'om  definable 
objects  without  the  benefits  of  inheritance  or  polymorphism,  is  ready  to  be  the  next  great 
advance  in  softweire  development.  Although  the  concept  of  constructing  applications 
with  reusable  code  as  been  available  since  the  object-oriented  revolution,  it  is  only  just 
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recently  that  critical  mass  has  occurred  in  the  computing  industry.  The  pieces  are  in  place 
for  component-based  application  development  to  achieve  mainstream  status  amongst 
today’s  IT  organizations.  (Chappell,  1997,  p.  1) 

The  major  reasons  for  this  are: 

•  The  growing  use  and  acceptance  of  Microsoft’s  Component  Object  Model 
(COM)  as  the  dominant  standard  for  PC-based  component  computing. 

•  Components  are  moving  off  the  desktop  and  beginning  to  play  an  important 
•  role  in  the  creation  of  client/server  applications. 

•  Broad  support  for  designing  and  developing  components  and  component- 
based  applications  with  third-party  tools  and  languages.  (Chappell,  1997,  p. 

3) 

As  a  developmental  process,  component-based  development  (CBD) 

“...will  supplant  earlier  programming  archetypes,  such  as  structured 
programming  and  object-oriented  programming,  as  the  approach  most 
likely  to  yield  significant  productivity  and  reusability  benefits.  Its 
emphasis  on  iteration  sounds  the  death  Imell  for  the  traditional  ‘waterfall’ 
model  of  the  entire  development  process.  One  of  the  reasons  that  CBD 
will  gain  broad  acceptance  is  that  it  offers  ways  to  address  the  complete 
range  of  software  challenges,  from  operating  system  services  to 
client/server  development.”  (Spitzer,  1997). 

Component-based  development  is  not  without  its  own  baggage,  however.  As 
more  and  more  organizations  and  vendors  shift  their  focus  to  take  advantage  of  this  new 
wave  in  computing,  the  more  susceptible  they  will  become  to  the  unintended 
consequences  of  the  “revolution.”  One  of  the  biggest  challenges  in  the  component- 
oriented  “revolution”  so  far  is  the  utter  lack  of  any  kind  of  established  methodology  for 
effectively  guiding  the  conceptualization,  analysis,  and  implementation  of  a  user-centric 
application,  or  managing  component-based  construction  from  infrastructure  components. 

Additionally,  there  is  not  a  widely  accepted  standards-based  component 
architecture  from  which  to  develop  applications.  Compoimding  this  problem  is  the  fact 
that  almost  every  component-oriented  solution  is  unique  in  its  configuration  and 
implementation.  Traditional  software  development  methods  do  not  apply.  The  model 
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currently  most  applicable  is  the  one  an  organization  develops  for  its  own  IS  operations 
and  IT  environment  (Hamilton,  1994,  p.  43). 

The  other  reality  is  that  open  component  architectures  —  with  their 
interdependent  servers,  databases,  clients,  and  protocols  —  have  a  multitude  of  potential 
connection  point  failures”  (Hamilton,  1994,  p.  43).  Although,  we  are  still  better  served 
by  past  software  development  practices,  it  continues  to  remain  horribly  expensive  to 
construct  custom  software  for  automating  a  particular  organization’s  unique  business 
processes  (Udell,  1994,  p.  47).  “...Today’s  major  problems  with  software  [development] 
are  not  technical  problems,  but  management  problems”  (DOD-USD,  1987).  Developers 
need  an  efficient  means  in  which  to  manage  and  “pre-engineer”  modular  applications, 
databases,  and  information  flows  prior  to  deployment  in  a  real  world  environment. 
Because  the  systematic  construction  of  complex  software  applications  from  existing 
components  remains  an  ever  elusive  goal  (Garlan  et.  al.,  1995,  p.  17). 

From  a  technical  perspective,  a  combination  of  component-based  development 
and  the  latest  advancements  in  software  architecture  such  the  ARIES  SDSS  is  required. 

The  prerequisites  for  this  would  need  to  include: 

•  A  \videly  accepted  component-oriented  infrastructure. 

•  Standard  Domain-Specific  Software  Architectures  (DSSA)  to  guide 
development  and  enable  rapid  assembly. 

•  Commercial  and  technical  environments  that  fully  support  CBD  integration. 

This  alone  may  be  the  most  important  paradigm  shift  in  software  development  in 
decades.  The  dawn  of  the  “industrial  revolution  of  software,”  whereby  software  products 
are  manufactured  in  accordance  with  a  specified  structure  and  process,  is  upon  us. 
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3.  Architectonic  Paradigm;  The  Shift  to  Structure 

“Today  the  term  [paradigm]  is  widely  used  to  define  a  broad  model,  a  framework, 
a  way  of  thinking,  or  a  scheme  for  understanding  reality”  (Tapscott,  1993,  p.  xii).  The 
Architectonic  Paradigm  —  of  or  pertaining  to  principles  of  architecture  —  mandates  a 
shift  in  conventional  thinking  about  how  developers  build  applications.  It  requires  an 
architectural  approach  that  spans  both  the  business  and  technical  arenas,  and  that  adopts 
the  perspective  of  software  construction  not  as  a  craft  but  as  a  discipline  (Davis,  1995). 

This  new  paradigm  consists  appropriately  of  the  following  aspects: 

•  Simplicity  -  easy  to  comprehend  and  communicate. 

•  Task-centric  -  must  map  naturally  to  the  customers’  world. 

•  Changeable  -  enable  rapid,  flexible,  and  scaleable  paths. 

•  Manageable  -  support  heterogeneous  platforms,  applieations  and  architectures. 

•  Leverageable  -  migrate  legacy  systems  and  support  COTS  integration. 

In  short,  the  Architectonic  Paradigm  is  one  in  which  the  overall  focus  shifts  fi'om 
requirements-driven  to  architectural-driven  development.  It  “has  all  the  benefits  of 
requirements-driven  style,  as  well  as  the  favorable  characteristie  of  encouraging  the 
creation  of  resilient  frameworks  that  can  withstand  shifting  requirements  and 
technological  calamity”  (Booch,  1996,  p.  21).  But  the  days  of  designing  an  information 
system  in  a  vacuum  are  over.  The  problems  of  today  are  up  to  50  times  larger  in 
complexity  than  the  problems  of  yesteryear,  and  the  difficulty  of  developing  “good 
enough”  solutions  is  growing  at  an  exponential  rate.  The  developer  is  always  trying  to  fit 
a  new  piece  into  a  puzzle  that  has  already  been  framed  and  to  deal  with  quirky  methods  of 
interfacing  with  the  database(s).  A  developer  can  no  longer  afford  to  build  software 
applications  from  scratch  without  duly  considering  the  existing  infirastructure  and  several 
components  —  which  are  themselves  architectures  (information,  application,  and 
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technical)  —  contained  within  the  structure.  The  Infrastructure  investment  holds  a 
central  position  in  any  planned  and  future  application  development  (Figure  3-1). 
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Figure  3-1.  An  Architecture-Driven  System.  After  (Booch,  1996,  p.  52). 

4.  Infrastructure:  The  Invisible  Hand  of  Structure 

The  previous  chapter  briefly  introduced  the  notion  of  architecture-driven 
programming  and  illustrated  how  it  relates  to  infrastructure.  The  central  idea  is  to 
encourage  the  minimal  programming  of  new  applications  by  using  software  architectures 
and  COTS  products  already  present  within  the  desired  operating  environment.  An 
example  in  a  Windows-based  environment  would  be  to  develop  an  application’s  U/I 
using  Window’s  API  routines  rather  than  creating  new  objects  and  classes  in  the  C-H- 
language.  Additionally  the  use  of  validated  infrastructure  components  require  that  new 
applications  only  need  to  be  tested  at  the  points  of  interaction  between  existing 
components  and  thoroughly  tested  for  any  custom  designed  components.  This  allows  the 
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developer  to  safely  assemble  and  application  as  opposed  to  building  it.  The  guiding 
principle  is  '‘‘'Buy  the  Basics,  Custom  Build  only  what  provides  Value’’’  (Knowles,  1997). 

Many  mature  organizations,  already  dependent  on  information  systems,  are 
struggling  to  implement  this  “Best-in-Breed”  approach  while  still  maintaining  their 
existing  lines  of  business  applications.  To  accomplish  this,  organizations  must 
effectively  forge  a  vision  for  an  enterprise  architectural  foimdation  with  a  (capital  “A”) 
and  develop  domain-specific  frameworks  that  support  the  integration  of  single  application 
architectures  (with  a  lower-case  “a”).  Perhaps,  the  best  approach  is  to  fundamentally 
leverage  the  existing  infrastructure  in  a  manner  that  permits  organizations  and  developers 
to  manage  heterogeneous  components,  business  rules,  and  legacy  data  from  an 
architectural  perspective. 

The  ARIES  development  team  devised  the  Baseline  Infrastructure  Archetype 
(BIA)  Model  to  accomplish  this  objective,  and  to  better  understand  and  analyze  the 
infrastructure.  Although  the  BIA  Model  is  generic,  it  forms  the  centerpiece  of  the 
Architectonic  Paradigm,  and  offers  guidance  for  evaluating  the  features  of  available 
components  and  tools  used  to  solve  problems  relevant  to  the  unique  circumstances  of 
individual  applications.  Essentially  all  of  the  pertinent  technology  fits  into  the  multi¬ 
layer  triangular  model  (Figure  3-2)  that  incorporates  all  three  infi^structure 
subarchitectures:  information,  application,  technical.  These  subarchitectures  provide  a 

triad  of  interaction  for  all  systems  within  the  Architectonic  Paradigm: 

•  Information  Architecture  -  describes  the  content,  behavior,  and  interaction  of 
all  the  business  and  information  requests  from  applications  and  technical 
components.  The  information  architecture  provides  the  database  objects  and 
services  for  application  development  and  provides  a  information  framework 
for  other  requesting  resources. 

•  Application  Architecture  -  defines  the  fundamental  services  and  business 
rules  within  the  applications  domain.  This  architecture  transparently  and 
seamless  supports  the  logic  and  data  processing  of  the  user  interface  service 
requests.  The  components  of  the  information  architecture  are  modeled. 
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designed,  and  implemented  in  terms  of  the  business  rules  and  processes 
developed  in  the  application  architecture. 


•  Technical  Architecture  -  specifies  the  actual  technologies  (components)  and 
the  software  tools  that  supply  the  requested  services  to  and  fi'om  the 
application  and  information  architectures.  It  is  used  to  implement  the 
applications.  (Aronica  and  Rimel,  1996) 


Figure  3-2.  Baseline  Infrastructure  Archetype  (BIA)  Model. 


The  logical  layers  of  the  BIA  Model  that  function  from  the  epicenter  (interface  layer) 
outward  are: 

•  Interface  Layer  -  Provides  client-side  services  to  the  resources  and  user.  For 
a  particular  user  the  layer  enables  access  and  interaction  with  application 
resources. 

•  Communications  Layer  -Functions  as  middleware  to  cormect  and  manage  the 
interface  clients  with  various  requested  resources. 
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*  Resources  Layer  -  Consists  of  the  DBMS,  databases,  and  data;  the 
applications,  parts  of  applications  and  components;  technologies  and  tools  that 
implement  the  applications.  (Hurwitz,  1997) 

Resource  interactions  that  do  not  require  client  involvement  occur  at  the  angular 
margins,  and  the  byproducts  of  interaction  are  conceptually  maintained  within  the  circular 
segments  of  the  “sphere  of  influence”.  More  simply,  the  sphere  represents  the  scalable 
world  in  which  the  information  system  functions.  Whether  it  is  a  standalone  desktop 
computer  or  a  mainframe  system,  the  baseline  structure  is  physically  different  but 
logically  similar.  The  ecological  environment  in  which  the  spherical  microworlds  operate 

provide  the  common  platform  services: 

*  Base  Operating  System  (e.g.,  Windows  NT). 

*  Networking  Communications  (e.g.,  NetBUI,  TCP/IP,  etc.). 

The  layers  in  this  model  are  not  the  same  as  those  found  in  a  typical  three- 
tier  client/server  model.  There  is  no  single  service  with  a  single  piece  of 
middleware,  no  single  graphical  user  interface,  and  no  single  type  of  data 
all  tightly  connected.  You  should  think  of  each  layer  as  a  category  ~  an 
organizing  principle.  (Hurwitz,  1 997). 

This  layer  approach  allows  developers  to  plan  the  function  of  various  pieces  of  the 
architecture  and  determine  what  to  work  on  first.  A  specific  example  of  this  model  will 
be  provided  later  in  the  next  section. 

The  next  logical  question  is  “How  can  the  benefits  of  architecture  be  effectively 
extended  to  component-based  computing?”  The  ARIES  development  team’s  response 
was  to  devise  and  institute  a  methodological  heuristic,  Concept-to-Code,  that  embraced 
the  Architectonic  Paradigm  and  provided  a  structural  perspective  and  the  means  to 
formulate  a  cohesively  integrated  application.  This  will  be  the  focus  of  our  discussion  in 
the  next  section. 
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C.  CONCEPT-TO-CODE  HEURISTIC 


1.  Overview 

The  main  disadvantage  of  major  information  system  development,  aside  from 
architectural  and  infrastructural  issues,  is  that  it  takes  too  long  to  implement  full 
production  products  from  untested  concepts.  It  is  very  difficult  to  get  beyond  theoretical 
constructs  to  practical  implementations. 

What  is  needed  is  a  new  kind  of  application  development,  one  supported  by  a  set 
of  design  ideas  that  can  accommodate  pre-existing  applications,  software  infrastructure, 
and  COTS  products,  and  one  employing  a  systematic  approach  independent  of  tool,  style, 
or  technique  that  acts  to  guide  and  direct  the  collaborative  efforts  of  the  users  and 
developers,  and  that  incorporates  Grady  Booch’s  five  elements  of  a  successful  project 
application: 

•  Focus  ruthlessly  on  the  development  of  a  system  that  provides  a  well- 
understood  collection  of  essential  minimal  characteristics. 

•  The  existence  of  a  culture  that  is  centered  on  results,  encourages 
communication,  and  is  not  afraid  to  fail. 

•  The  effective  use  of  object-oriented  analysis  and  design. 

•  The  existence  of  a  strong  architectural  vision  and  principles. 

•  The  application  of  a  well-managed  incremental  and  iterative  development  life 
cycle.  (Booch,  1996,  p.  25) 

Concept-to-Code  (C2C)  is  just  that:  a  way  of  getting  from  a  concept  envisioned 
by  a  organization  to  the  specific  computer  code  needed  to  achieve  it.  C2C’s  primary 
cognitive  focus  is  to  prevent  the  production  of  ill-defined  software  early  in  the 
conceptualization  process.  The  heuristic  achieves  this  by  exploring  and  implementing 
practical  solutions  in  a  manner  that  is  independent  of  a  particular  computing  language. 
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DBMS,  and  operating  environment.  Simply  stated,  by  using  rapid  application 
prototyping  techniques  and  the  participatory  involvement  of  the  intended  users,  an 
organization  can  get  exactly  what  it  needs  in  less  time  than  by  conventional  methods. 

“In  business  system  development,  satisfying  the  needs  of  the  users  is  particularly 
challenging  because  even  the  user  cannot  know  what  he  wants  and  needs  until  he  sees  the 
system  in  action”  (Scharer,  1986,  p.  59).  Because  written  specifications  are  not  a  good 
way  to  communicate  with  the  user,  rapid  application  prototyping  was  selected  by  the 
ARIES  development  team  as  a  practical  approach  for  developing  the  U/I  and  the 
application.  Prototyping  in  this  case  becomes  a  method  of  system  construction  as  well  as 
a  technique  for  system  definition  (Scharer,  1 986,  p.  60).  Additionally,  it  is  critical  to 

remember  the  following  when  using  rapid  application  development  (RAD): 

•  RAD  only  works  when  you  vmderstand  the  business  problem. 

•  RAD  should  not  be  tool-driven  or  tool-dependent. 

•  RAD  is  only  effective  when  it’s  part  of  a  sound  application  development 
process.  (Linthicum,  1997) 

Achieving  this  RAD  effort  requires  close  communication  and  collaboration  between 

intended  users  and  a  small,  highly  skilled  development  team  (e.g.,  three  to  eight  people). 

The  task  is  to  develop  a  technical  artifact  for  a  client  or  user  with  more  or 
less  clear  and  stable  requirements.  To  cope  effectively  with  the 
uncertainty  of  this  task,  an  experimental  approach  is  taken  in  which 
various  models,  prototypes,  and  versions  are  tried  to  reach  a  satisfactory 
solution.  (Dahlbom,  1997,  p.  84) 

By  using  a  methodology  or  process  that  integrates  the  combination  of  controlled 
development  and  rapid  prototyping,  a  developer  can  ensure  minimal  risk  and  maximum 
benefit  in  design.  . 

In  order  to  effectively  organize  the  RAD  process,  C2C  yvas  visually  conceived  as 
a  three-layered  closed-loop  pyramid  structure  flowing  progressively  from  top  to  bottom 
and  iteratively  throughout  the  structure  (Figure  3-3).  Each  layer  represents  a  distinct 
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“phase  change”  of  the  collaborative  process,  or  the  completion  of  an  iterative  milestone 
of  the  developing  application.  Each  phase  is  further  sectionalized  into  two  smaller  parts 
called  “stages.”  As  indicated,  each  stage  flows  into  each  other  and  acts  to  facilitate  the 
focus  of  the  user  and  developer.  The  resultant  IN/OUT  processes  of  each  stage  are 
byproducts  of  this  interaction. 


The  Conceptualization  Phase  is  focused  on  identifying  and  clarifying  the  concept 
or  problem  to  the  extent  that  the  prospective  users  are  able  to  articulate  and  the 
developers  are  able  to  assimilate.  The  artifacts  of  the  conceptualization  phase  are  utilized 
by  the  Visualization  Phase  to  more  thoroughly  analyze  the  problem  domain,  define  and 
design  stable  component  architectures,  and  address  the  riskier  elements  of  the  project. 
This  phase  will  more  than  likely  require  several  iterative  feedback  loops  to  properly 
create  the  U/I  prototype  and  application  architecture  in  accordance  with  the  user’s 
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requirements.  The  Implementation  Phase  uses  the  approved  byproducts  of  the 
Visualization  Phase  employing  appropriate  application  development  principles  and  fourth 
generation  language  coding  skills  of  the  developers. 

Prior  to  the  transition  from  each  phase/stage,  a  formal  review  and  informal 
walkthrough  should  be  conducted  to  ensure  the  resultant  artifacts  are  satisfactory  and 
design  decisions  sound.  Usually  peer-to-peer  walkthroughs  prevent  a  perpetuation  of 
inconsistency  and  incompatibility  between  user  requirements  and  developer  objectives. 
“Formal  reviews  are  intended  for  acquisition  management  users  and  interested  parties  to 
conclude  a  software  development  phase  by  approving  the  products  and  other  results  of 
that  phase”  (USAF-STSC,  1992,  p.  55). 

A  completed  cycle  of  the  C2C  pyramid  and  acceptance  of  the  application  by  the 
user  represents  a  final  incremental  version  that  is  ready  to  be  deployed  in  the  desired 
operating  environment.  “The  process  is  incremental  in  the  sense  that  each  pass  through 
the...[C2C]  cycle  leads  a  project  to  gradually  refine  its  strategic  and  tactical  decisions, 
ultimately  converging  upon  a  solution  that  meets  the  end  user’s  real  (and  usually 
unstated)  requirements,  and  yet  is  simple,  reliable,  and  adaptable”  (Booch,  1996,  p.  29). 
Later  in  this  chapter,  I  will  specifically  address  each  phase  and  stage  in  turn,  but  for  now 
it  is  easier  to  view  each  phase  and  stage  as  a  transition  point. 

The  apex  of  the  pyramid  is  the  highest  point  of  general  abstraction  and  becomes 
more  specialized  as  the  developer  gravitates  to  the  foundation.  Only  as  the  user- 
developer  collaborative  ensemble  descends  the  structure  do  specific  conunitments  to 
particular  languages,  standards,  and  operating  environments  emerge,  all  the  while 
providing  a  mechanism  for  feedback  that  enables  arehitectural  refinement  and  iterative 
development  of  the  concept.  The  bisection  of  the  upper  half  (user-driven)  and  lower  half 
(developer-driven)  of  the  pyramid,  indicates  the  primary  focus  of  the  collaborative  effort. 
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The  shaded  boxed  regions  in  the  first  two  phases  illustrate  where  rapid  prototyping  occurs 
dependent  on  user  requirements: 

The  Analysis  Prototype  is  an  aid  for  exploring  the  problem  domain.  It  is 
meant  to  capture  users’  input  and  show  proof-of-concept.  The  analysis 
prototype  is  not  meant  to  be  used  as  a  basis  for  development  and  it  should 
be  discarded  when  it  has  served  its  purpose.  The  final  product  should  use 
the  concepts  exposed  by  the  prototype,  not  its  code. 

The  Domain  Prototype  is  an  aid  for  the  incremental  implementation  of  the 
solution.  It  can  be  used  as  a  tool  for  staged  delivery  of  subsystems  to 
users  and  other  developers.  It  demonstrates  the  feasibility  and  viability  of 
the  implementation  and  will  eventually  evolve  into  a  deliverable  product. 

(Tkach,  1996,  pp.  52-53) 

Therefore  the  amount  of  prototyping  is  directly  proportional  to  the  degree  the  user 
is  able  to  effectively  articulate  what  s/he  wants,  needs,  and  desires  (Figure  3-4).  This 
dependency  upon  the  judgmental  influence  of  the  user  diminishes  from  phase  to  phase 
(Figure  3-5).  Because  of  this  dependency  the  prototyping  for  the  ARIES  SDSS  will  be 
discussed  separately  at  the  end  of  each  phase  narrative  —  each  prototype  situation  is 
uniquely  different  from  the  previous,  and  at  a  minimum,  the  U/I-centric  nature  of  today’s 
applications,  increasingly  demands  prototyping  to  achieve  the  best  fit,  form  and 
functionality  in  a  very  short  time. 

This  coordinated  prototyping  capability  is  what  makes  C2C  far  different  from 
typical  application  development.  It  lends  itself  easily  to  rapid  application  development 
yet  is  iterative  at  each  phase.  “Without  a  [process]  for  managing  change,  all  but  the 
smallest,  simplest  projects  are  at  risk  of  wandering  out  of  control  and  adding  time  to  the 
development  schedule”  (Forte,  1997,  p.  121).  The  heuristic  on  the  whole  is  not  a  cookie- 
cutter  technique,  but  takes  a  “systems  view”  of  the  concept  to  be  tested  and  develops  the 
application  in  steps  from  concept  to  system  to  subsystem. 
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Conceptualization  Visualization  Implementation 

Phase  Phase  Phase 


Figure  3-5.  User  Influence  on  Application  Development. 
With  this  in  mind,  a  more  complete  definition  of  C2C  is  the  following: 


C2C  is  a  formalized  iterative  construct,  a  heuristic,  for  developing 
“proof-of-concept”  applications  in  a  top-down,  component-orient^ 
architecture  in  which  users’  objectives,  business  rules,  and 
organizational  data  are  defined  and  related  to  one  another  at  the 
conceptual,  technical,  and  implementation  levels. 
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The  tenet  principles  upon  which  this  heuristic  was  based  are  as  follows: 

•  Manage  the  complexity  of  small  to  medium  sized  applications  (<  100,000 
LOC)  through  the  use  of  component-based  techniques  while  still  embracing 
legacy  systems. 

•  Focus  development  and  modeling  efforts  on  components  whose  function  is 
determined  heavily  by  the  user  interface  and  interactions  with  relational 
databases. 

•  Where  applicable,  adapt  to  changing  requirements  by  maintaining  a  strict 
adherence  to  open  IT  standards-based  architectures  to  ensiue  interoperability, 
portability,  scalability,  and  data  exchange  (Libicki,  1994,  p.3). 

•  Ensure  application  efforts  are  user-driven,  not  technology-driven,  by 
leveraging  the  user  and  developers  intellectual  capital  through  rapid 
application  prototyping. 

•  Conduct  integrated  and  continuous  testing  with  the  C2C  process  while 
maintaining  a  “high  level  of  stability  throughout  the  project  by  constantly 
evaluating  the  architecture,  interfaces,' and... by  preventing  the  accumulation  of 
latent  defects”  (Forte,  1997,  p.  122). 

Now  that  the  basics  and  underlying  principles  of  C2C  have  been  explained,  we 
can  delve  into  the  specific  regions  of  the  heuristic  and  how  they  help  to  direct  the 
development  of  the  ARIES  application. 


2.  Conceptualization  Phase 


Concept-based  exploration  begins  with  a  broad  concept  —  a  “term... meant  to 
suggest  a  framework  that  is  found  useful  in  organizing  ideas  and  suggesting  actions”  — 
and  proceeds  into  a  characterization  plan  to  determine  and  understand  the  processes  of  the 
organization,  and  identify  the  top  level  requirements  and  feasibility  of  the  concept  (Scott- 
Morton,  1984).  It  is  essential  to  understand  the  business-centric  aspects  of  the 
organization  prior  to  developing  the  concept.  The  main  goal  in  the  first  step  of  this  phase 
is  to  identify  the  concept  to  be  proven,  and  characterize  it  in  terms  with  which  the  user  is 
familiar  in  preparation  for  later  software  development. 
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The  second  step  in  the  conceptualization  process  is  identifying  the  specific 
capabilities  required  to  execute  the  concept  by  focusing  on  defining  as  much  as  possible 
the  elements  that  best  characterize  the  organization’s  stated  concept.  The  goal  is  to 
develop  a  characterization  of  what  the  application  will  accomplish  without  getting  into 
the  details  of  how  the  system  actually  functions.  The  term  characterization  is  used 
because  process  analysis  and  data  gathering  are  not  exhaustive.  It  is  not  necessary  to 
document  every  detail.  Only  enough  detail  is  required  to  allow  informed  decisions  to  be 
made  in  the  creation  of  the  component  architectures  and  U/I  prototype.  Without  the 
insight  that  a  baseline  characterization  provides,  there  is  a  risk  of  devising  a  system 
architecture  that  is  difficult  to  improve.  If  the  customer  already  possesses  much  of  the 
baseline  data,  more  time  can  be  spent  on  characterizing  the  environment.  Iterative 
development  will  subsequently  refine  the  characterization  to  a  specific  system. 

Much  of  this  information  is  gathered  through  a  process  of  interviews  with  all  the 
individuals  (Management,  IT  staff,  and  end  users)  with  a  vested  interest  in  the 
application;  as  well  as  a  thorough  audit  of  the  existing  environment.  It  is  important  that 
the  intended  users  of  the  system  be  fully  involved  and  participative  in  the  conceptual 
design  process.  Conceptual  errors  made  in  the  design  are  laboriously  difficult  to  correct 
once  coding  has  begun.  Developers  prefer  to  carefully  analyze  and  evaluate  the 
conceptual  design  before  proceeding  to  the  Visualization  Phase.  If  the  user  has  difficulty 
articulating  or  characterizing  the  concept,  it  is  the  responsibility  of  the  development  team 
to  utilize  prototyping  as  a  means  to  elicit  the  desired  information.  The  Analysis 
Prototype  can  help  to  “minimize  development  risks  due  to  incomplete  requirements,  and 
to  assess  whether  a  user  interface  can  be  developed  that  will  allow  the  designated  system 
to  operate  effectively”  (Dolan,  1994). 

Some  of  the  basic  concept  characterization  elements  to  consider  are  (not 
inclusive): 
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•  Top-Level  Requirements. 

•  Scope. 

•  Timeline  for  Product  Delivery. 

•  Performance  Criteria. 

•  Technology  Base  and  Infrastructure. 

•  Business  Rules,  Processes  and  Logic. 

The  user  is  not  asked  to  freeze  the  functional  specifications  during  this  because 
specifications  can  be  revised  or  changed  even  after  the  analysis  prototype  refinement  is  in 
progress.  Accordingly,  this  will  require  a  different  mind-set  than  previously  conducted 
by  software  development  teams  in  tlie  past. 

a.  ARIES  Concept  Stage 

The  concept  US  ARC  was  interested  in  investigating  was  whether  or  not 
the  manual  process  of  relocating  Army  Reserve  units  could  be  automated  using  existing 
data  sources  and  computing  infrastructure.  Specifically,  could  a  Geographic  Information 
System  (GIS)  be  integrated  with  an  ARU-Decision  Model  to  provide  users  with  the 
ability  to  graphically  select  and  compare  reserve  units  through  a  common  user  interface. 
The  resultant  solution,  a  Spatial  Decision  Support  System  (SDSS),  would  be  a  new 
capability  that  allows  the  decision-maker  to  “pull”  only  the  spatially  pertinent  data  about 
desired  facilities  and  “push”  the  results  into  the  DSS  model. 

b.  ARIES  Characterization  Stage 

The  desired  ARIES  system  could  best  be  characterized  as  a  software 
application  that  spatially  selects,  derives,  calculates,  and  imports  the  user-identified 
decision  parameters  into  the  ARU-DM  using  USARC  data  sources. 
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( 1 )  Top  Level  Requirements 

•  SDSS  application  must  be  a  standalone  “proof-of-concept”  prototype  that  will 
execute  on  a  USARC-furnished  laptop  computer  miming  the  Microsoft 
Windows  95  operating  system. 

•  Allow  the  decision-maker  to  manage  the  selection  of  the  legacy  data  sources 
ontheUSARCLAN. 

•  Implement  a  single,  consistent  user  interface  that  allows  the  decision-maker  to 
graphically  or  manually  select  the  facilities  to  be  compared. 

•  Automate  the  calculation  of  ARU-DM  parameters,  using  USARC  business 
mles,  pre-determined  data  processes,  and  a  GIS. 

•  Enable  the  batch  printing  of  pre-determined  reports  from  a  default  preference 
set. 

•  Allow  the  decision-maker  to  change  parameter  weightings  and  conduct  “what- 
if  ’  analysis  on  the  completed  scenario. 

•  Use  as  many  USARC  infrastructure  components  as  possible  without  adding 
additional  administrative  burden  to  the  IT  staff. 

(2)  ARIES  Scope 

•  Data  Sources  -  U.S.  Army  Reserve  Databases  (National);  Approximately  one 
gigabyte.  The  functionality  of  the  SDSS  had  to  be  proven  with  USARCs’ 
existing  systems,  using  data  the  decision-makers  were  familiar  with. 

•  Inputs  -  Unit  Identification  Code  (UIC)  of  the  moving  imit  and  up  to  four 
Facility  Identification  (FacID)  unit  alternatives. 

•  Complexity  -  Support  no  more  than  10  USARC  users  at  a  time  in  the  LAN 
environment. 

•  Constraints  -  For  calculating  applicable  decision  parameters,  spatially  select 
the  closest  AMSA,  equipment  and  recruiting  sites;  Conduct  all  spatial 
selections  within  a  50  mile  radius  of  the  proposed  site;  Use  USARC’s 
command  plan  as  a  master  list  to  validate  UIC’s  and  G17  files  as  the  master 
list  to  validate  FacID ’s;  Indicate  inaccurate  or  missing  data  for  decision 
parameters  with  code  (-999). 

(3)  Timeline 

•  Develop  standalone  prototype  in  approximately  six  months. 
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(4)  ARIES  Performance  Criteria 

•  Conduct  each  evaluation  scenario  (up  to  four  alternatives)  within  two  hours 
maximum;  Verify  each  user  input  using  master  validation  lists;  Batch 
automate  as  much  as  possible  in  order  to  minimize  user  interaction  and 
training. 

(5)  USARC  Technology  Base  and  Infrastructure 

•  Hardware  (standalone)  -  Dell  Latitude  laptop  computers  with  90  MHz 
Pentium  processors. 

•  Hardware  (network)  -  Numerous  multi-vendor  desktop  computers  with 
Pentium  Processors. 

•  Operating  Systems  -  USARC  LAN  ruiming  Microsoft  Windows  for 
Workgroups  3.1  with  a  plan  to  upgrade  to  Microsoft  Windows  NT  4.0  in 
Fiscal  Year  1997.  USARC  laptops  utilize  Windows  95. 

•  COTS  -  Mapinfo  Professional  and  MapBasic  4.0  mapping  software  package. 
Microsoft  Office  95  Suite. 

•  4GL  -  Microsoft  Visual  Basic  4.0  Professional  Edition. 

(6)  ARIES  Business  Rules  and  Processes  --  Appendix  B 


c.  ARIES  Analysis  Prototype 

Because  users  cannot  always  articulate  what  their  business  requirements 
are  or  their  preferences  for  the  user  interface,  two  forms  of  analysis  prototyping  were 
used  to  better  conceptualize  the  ARIES  system. 

(1)  Contextual.  Because  direct  interaction  between  USARC 
and  NPS  was  restricted  to  a  maximum  of  two  days  per  month  a  contextual  style  (story¬ 
boarding)  of  prototyping  was  used  to  elicit  from  the  users  the  desired  functionality  of  the 
common  user  interface  in  terms  of  visual  appearance,  menu  choices,  program  controls 
and  toolbar  capability.  The  idea  was  to  distill  the  “signal  from  the  noise”  by  starting  from 
the  user’s  perspective  and  rapidly  discussing,  diagramming,  and  receiving  feedback  about 
various  interface  ideas  and  alternatives.  As  each  iterative  cycle  was  completed,  the 
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interface  became  more  refined,  until  all  sides  agreed  upon  a  interim  design.  The  final 
computer-based  design  was  completed  later  as  a  byproduct  of  the  component  architecture 
prototype  in  the  Visualization  Phase. 

Because  the  application  was  to  execute  in  a  Microsoft  Windows- 
based  environment,  it  was  important  to  the  users  that  the  user  interface  mimic  and 
leverage  Windows-based  functions  as  much  as  possible.  The  main  objective  was  an 
application  that  required  a  minimum  amount  of  training  for  experienced  Windows  users 
and  fulfilled  all  of  the  stated  requirements.  To  achieve  this,  the  collaborative  team  agreed 
that  all  program  views  and  controls  would  be  subordinate  to,  and  represent  only  one  item 
at  a  time  within  the  confines  of  a  master  window  view.  This  was  needed  to  maximize 
user  comprehension  and  minimize  confusion.  The  particular  views  and  controls  are  as 
follows: 

•  Provide  a  Map  View  that  enables  the  user  to  graphically  select  desired  imits 
and  monitor  the  progress  of  facility  comparisons  that  are  spatially  selected  and 
calculated. 

•  Provide  a  Selection  Panel  that  enables  the  user  to  manually  input  Moving 
UIC/FacIDs  and  monitor  the  status  of  facility  comparison  calculations. 

•  Implement  button  controls  for  accepting,  starting,  resetting  and  exiting  the 
application. 

•  Implement  a  menubar  and  toolbar  that  allows  the  user  to  manipulate  the 
COTS  products  in  accordance  with  user  requirements. 

•  Provide  feedback  to  user  in  the  form  of  a  statusbar  and  a  selected  facility 
information  view. 

(2)  RAD-based.  A  second  analysis  prototype  used  a 
combination  of  4GLs,  Delphi  2.0,  Visual  Basic  and  MapBasic,  to  develop  a  rapid 
application  to  audit  and  validate  the  USARC  business  rules  and  data  logic  for  deriving 
the  ARU-DM  parameters.  This  was  accomplished  by  creating  relational  database  links  to 
a  subset  of  the  data  sources  —  Army  Reserve  Units  in  Pennsylvania  —  in  their  existing 
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format,  computing  the  decision  parameters  in  accordance  with  the  business  rules,  and 
outputting  the  results  to  a  common  data  file  format  (e.g..  Tab  delimited).  Additionally,  a 
custom  component  was  created  and  developed  using  the  MapBasic  spatial  application 
development  language;  a  programming  language  associated  with  interacting  and 
automating  the  Mapinfo  application.  Essentially,  the  MapBasic  component  functioned  as 
a  workflow  script  that  spatially  selected  the  data  necessary  to  calculate  several  decision 
parameters  within  a  50  mile  radius.  This  proved  to  the  collaborative  team  that  the  most 
critical  aspect  of  the  prototyping  process,  using  US  ARC  LAN  files  without  modification 
and  coordinating  various  heterogeneous  COTS  products,  could  be  controlled  by  a 
common  user  interface.  By  prototyping  ARIES  in  this  way,  we  were  able  to  obtain  clear 
guidance  on  how  to  meet  and  comply  with  USARC’s  unique  military  requirements  and 
business  rules. 


d.  ARIES  Conceptualization  Artifacts 

Before  proceeding  to  the  next  phase,  a  formal  walkthrough  review  was 
conducted  with  all  involved  to  ensure  all  user  requirements  had  been  gathered  and  the 
concept  properly  characterized.  It  was  important  to  avoid  “gold  plating”  the  requirements 
(e.g.,  providing  more  functionality  and  features  then  the  user  needs)  by  realistically 
examining  the  application’s  proposed  concept  and  the  organizations  existing  IS/IT 
infi’astructure.  The  resultant  ARIES  artifacts  of  this  phase  were  determined  to  be  the 

following  and  are  detailed  in  Appendix  C: 

•  Conceptual  Overview  Diagram 

•  ARIES  Process-Flow  Diagram. 

•  USARC  Business  Rules  Specifications  (Appendix  B). 

•  User  Interface  Interim  Layout. 

•  User  Interface  Final  Layout 
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3.  Visualization  Phase 


Once  the  business  issues  are  characterized  and  the  application  requirements  have 
been  defined,  the  next  step  is  to  turn  these  abstract  requirements  into  an  actual  tangible 
architecture.  The  Visualization  Phase  does  this  by  providing  the  means  to  synthesize  the 
user  requirements  into  functional  architectures  and  component  interactions.  Unlike 
current  software  development  practices,  C2C  does  not  attempt  to  clarify  tiie  difference 
between  requirements  and  design.  The  goal  is  to  facilitate  the  construction  of  the  needed 
application  using  the  most  appropriate  architectures. 

The  C2C  architecture  design  involves  multiple  levels  of  abstraction.  At  one 
extreme  is  the  reference  or  domain-specific  software  architecture  (DSSA);  the  other  is  the 
application  architecture  itself.  The.  DSSA  represents  the  most  general  and  abstracted 
form  whereas  the  application  architecture  represents  a  specific  design  solution.  In  this 
phase,  we  categorize  the  two  architectures  as  macro  and  micro.  The  macro-architecture 
illustrates  the  “what”  and  the  micro-architecture  illustrates  the  “how”  of  the  application 
being  designed.  While  the  micro-architecture  represents  a  specific  technical  solution  and 
will  change  as  the  application  is  revised,  the  functional  macro-architecture  will  remain 
the  stable  domain  structure.  Based  on  the  requirements  identified  in  the  previous  phase, 
the  macro-architecture  is  partitioned  into  modules  and  the  function(s)  of  each  module  are 
defined.  The  micro-architecture  then  entails  the  identification  and  selection  of 
component  software  to  fulfill  theses  functions.  More  simply,  the  micro-architecture  key 
concerns  are  functionality  and  performance;  whereas  the  macro  level  concerns  focus  upon 
the  management  of  complexity. 

One  of  the  problems  of  identifying  components  is  that  future  users  of  the 
application  often  view  all  of  their  processes  as  unique,  and  therefore  desire  custom-design 
components  to  handle  this  uniqueness.  This  is  where  a  proper  balance  of  “Buy  -versus- 
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Build”  strategy  is  needed  by  application  developers;  because  some  of  the  components 
may  be  available  in  the  form  of  COTS  products,  and  some  components  may  have  to  be 
custom  developed  for  the  specific  function  they  are  required  to  implement.  A  good  rule 
of  thumb  is  “Build  Business  Value,  Buy  the  Basics”  (Knowles,  1997).  Secondly,  a 
component  should  be  linked  to  an  accepted  standard  and  it  must  earn  its  way  into  the 
application  architecture.  The  use  of  architectural  styles  such  as  these  have  several 
significant  benefits: 

•  Promotes  design  reuse  within  the  problem  domain. 

•  Often  leads  to  significant  code  reuse  and  shared  implementations. 

•  Enables  better  comprehension  of  the  system’s  organization  if  conventional 
structures  are  used. 

•  Use  of  standardized  styles  supports  interoperability. 

•  Permits  specialized  analysis  by  constraining  the  design  space.  (Monroe,  1997, 
p.45). 

We  envision  multiple  passes  through  the  Visualization  Phase  with  the  macro¬ 
architecture  being  solidified  first,  the  U/I  in  subsequent  passes,  and  finally  the  component 
architecture  (micro).  Refinement  occurs  at  each  iteration  with  the  end  user  closely 
engaged  in  the  resultant  architecture. 

I 

a.  ARIES  Macro-Architecture  Stage 

Because  SDSS  was  an  innovative  concept,  there  was  no  pre-existing 
reference  architecture/DSSA  upon  which  to  base  our  design.  With  this  in  mind,  the 
collaborative  team  utilized  the  artifacts  from  the  previous  phase  and  the  BIA  model  to 

design  a  macro-architecture  (Figure  3-6): 

•  Point  of  Access  (POA)  Module  -  the  prototyped  U/I 

•  Application  Module  -  includes  the  ARIES  Business  rules  and  processes  to 
capture  the  ARU-DM  decision  parameters  and  transfer  them  to  the  DSS. 
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•  Technical  Module(s)  -  includes  the  capabilities  to  display  maps,  spatially 
select  data  and  provide  decision  support. 

•  Information  Module  -  includes  the  requisite  data  and  business  rules  to  support 
the  mapping,  decision  parameter  calculation,  and  decision  support  flmctions  in 
the  form  of  a  Data  Container. 


Figure  3-6.  ARIES  Baseline  Infrastructure  Archetype  (BIA)  Model. 


Because  the  movement  of  data  between  USARC  legacy  data  sources  and 
SDSS  modules  has  the  largest  data  flows,  the  development  team  implemented  a  container 
approach  to  manage  all  data  flows  within  the  context  of  the  macro-architecture  (Figure  3- 
7).  The  Data  Container  represents  an  abstracted  data  repository  that  contains  all  the  meta¬ 
data,  source  data  and  COTS  support  data  necessary  to  the  relocation  decision,  and 
provides  a  means  for  ARIES  to  be  portable  for  mobile  users  and  to  operate  independently 


from  the  USARC  LAN  for  networked  users.  Source  data  is  migrated  to  a  separate 

database  structure  (data  migration  warehouse  —  DataDepot)  for  the  following  reasons: 

•  Provide  an  accurate,  centralized,  and  high  quality  —  data  repository  for 
calculating  decision  parameters. 

•  Principle  of  minimality  -  only  use  whatever  data  is  required  to  support  reserve 
unit  site  selection. 

•  Accelerate  data  exchange  between  modules  by  using  the  native  DBMS  format 
of  the  USARC  infrastructure. 


b.  ARIES  Micro-Architecture  Stage 


After  considering  a  number  of  candidates  and  conducting  an  infrastructure 
review;  the  development  team  identified  the  primary  technologies  that  fit  the 
organizational  objectives,  with  which  to  populate  the  macro-architecture  (Table  III).  The 
information  within  the  Data  Container  component  represents  the  migrated  USARC 
source  data  necessary  to  support  the  relocation  decision  analysis  (DataDepot);  the 
Mapinfo  data  files  necessary  to  support  the  display  of  maps  and  geocoded  information; 
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and  the  ARU-DM  master  templates  to  support  the  importation  of  computed  decision 
parameters. 


Macro-Architecture  ■ 
Module  ^ 

V,  Reasons  for 
\  Selection  ■  , 

Communication 

Protocol 

ARIES  User 

Interface 

Visual  Basic  4.0 
Application 

US  ARC 

Requirement 

Various 

ARIES  Business 
Rules 

Visual  Basic  4.0 
Application 

Decision  Support 
System 

Logical  Decisions 
for  Windows. 

Only  DSS  COl  S 
product  capable  of 
auto-weighting. 

Data  Container 
(DataDepot) 

Microsoft  Access 
Database 

Performance  gam 
from  using  Native 
DBMS  vice  Third- 
Party  (ODBC) 

■■ 

Table  III.  Macro  and  Micro  Architecture  Comparison  Chart. 


Interoperability  between  components  can  be  achieved  by  a  variety  of 
means,  but  it  must  be  delineated  in  the  architectural  framework  and  applied  consistently 
throughout  the  application.  In  the  case  of  ARIES,  many  various  communication 
protocols  had  to  be  used  to  ensure  proper  component  iteration.  For  example,  because  the 
LDW  application  was  originally  designed  for  a  16-bit  Windows  environment,  it  was 
incapable  of  being  controlled  via  established  distributed  computing  standards  (e.g.,  OLE). 
Therefore,  the  development  team  used  intrinsic  Windows  Application  Programming 
Interface  (API)  routines  to  manipulate  the  LDW  window  displays  and  the  Visual  Basic 
SendKeys  Fxmction  to  process  macro-scripts.  In  short,  the  ARIES  U/I  controls  LDW  by 
simulating  a  user’s  input. 
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c.  ARIES  Domain  Prototype 

Although  each  of  the  technologies  brought  strengths  that  US  ARC  wanted 
to  take  advantage  of,  integration  of  the  components  into  a  coherent  process  that  could  be 
controlled  from  a  single  point  soon  became  a  formidable  challenge.  The  developers  were 
faced  with  the  difficulty  of  minimizing  the  coupling  and  data  transfer  between  the  major 
components  in  order  to  maximize  application  performance.  The  first  step  —  was  for  the 
development  team  to  fully  understand  all  of  the  components  —  including  their  design 
intentions,  capabilities,  strengths,  weaknesses  and  external  communication  protocols. 
The  second  step  —  was  to  partition  the  U/I  views  of  the  analysis  prototype  into  smaller 
segments  and  put  the  riskiest  parts  at  the  top  of  the  prototype  list,  rather  than  letting  them 
slip  to  the  end.  This  “Piece-of-the-Pie”  or  subset  approach,  allowed  the  developers  to 
bind  each  U/I  view  in  turn  to  the  applicable  component  (Table  IV). 

By  using  RAD  prototyping,  the  development  team  was  able  to  build  the 
interface  quickly  and  easily  using  a  visual  development  methodology  (VDM),  and  then 
using  component-based  development,  to  link  the  U/I  to  existing  data  sources, 
infrastructure  and  components  to  ensure  connectivity.  Later  in  the  Implementation  Phase 
the  team  would  place  the  appropriate  code  for  business  rules  and  data  manipulation 
behind  the  approved  user  interface.  In  this  manner,  the  abstract  interface  encapsulated,  or 
hid,  the  actual  system  implementation  from  the  end-users.  The  decision-maker  can  only 
view  and  access  the  system  by  way  of  this  single  point  interface. 


User  Interfdcel^ 
View  ^ 

^^MVrcMtecture  ;  ' 

Communication 

Protocols 

User  Inputs 

.  - 

•  Map  Select  l  ab 

•  Map  Query  Tab 

•  Maplnfo  4.0 

•  MapBasic  4.0 

•  OLE;  Dbase  111 

•  OLE;  Dbase  III 

•  (iraphically 
manipulate 
Maplnfo  tools 
(zoom-in, 
zoom-out, 
select,  grabber) 
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Information  Panel” 

Maplnfo  databases 
US  ARC  databases 
(Geo  Coded) 
DataDepot 

ODBC  (FoxPro) 
Dbase  III 

Scroll 

UP/DOWN 
Accept  Facility 
Info 

Facility  Selection 
Panel 

UataUepot 

JET  SQE 

Moving  Unit 
UIC 

FacID  (Qty  1- 
4) 

Control  Panel 

ARIES  U/1 

Visual  Basic  for 

Applications 

(VBA) 

IBS 

Table  IV.  ARIES  User  Interface/Micro-Architecture  Component  Binding. 


d.  ARIES  Visualization  Artifacts 


Before  proceeding  to  the  implementation  phase,  another  formal 
walkthrough  review  was  conducted  with  all  involved  to  ensure  that  the  proposed 
procedural  flows,  component  architectures,  and  U/I  prototype  were  practical,  close  to 
what  the  user  expected,  and  adhered  to  specified  standards.  Figure  3-8  illustrates  the  final 
approved  component  framework  solution. 


Front  -  End  (U/l)  □  Middleware  Protocols  £[]  Back  -  End  (Databases)  III  COTS  Products 


Figure  3-8.  ARIES  SDSS  Component  Framework  Solution. 
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4.  Implementation  Phase 


At  this  phase  in  the  C2C  process,  the  component  architectures  and  user  interface 
prototyped  in  the  Visualization  Phase  are  translated  into  source  code  in  3GL  or  4GL 
syntax.  If  an  RDBMS  is  involved,  the  database  schema  will  generated  and  integrated 
with  the  final  application.  The  purpose  of  the  coding  is  to  translate  the  detailed 
architecture  design  into  computer  language  suitable  for  the  designated  operating 
environment. 

Prior  to  this  stage  the  development  team  “must  first  agree  on  the  processes  and 
methodologies  it  intends  to  follow,  and  it  must  decide  which  of  those  processes  are  going 
to  be  followed  religiously  —  and  which  ones  will  be  honored  in  spirit,  but  perhaps  not  to 
the  letter  of  the  law”  (Yourdon,  1997).  Once  this  has  been  decided,  the  tools  and 
technology  can  be  chosen  —  or  rejected  —  accordingly. 

a.  ARIES  Development  Methods,  Techniques,  and  Strategies  Stage 

Once  the  application  has  been  designed  in  the  form  of  interacting 
components,  it  becomes  very  easy  to  add  new  ones  and  scale  up  the  functionality  of  the 
system  or  adapt  the  system  to  meet  a  design  constraint.  This  was  the  case  in  ARIES  for 
transferring  the  computed  decision  parameters  to  the  decision  support  system.  Because 
the  LDW  DSS  is  a  16-bit  Windows  application,  it  was  incapable  of  reading  Microsoft 
Access  database  files  without  a  custom  modification  by  LDW’s  development  team.  The 
solution  was  to  convert  the  Access  data  table  to  a  format  that  LDW  could  import  reliably. 
Component  testing  of  the  LDW  DSS  indicated  that  a  Tab-Delimited  format  was  the  most 
suitable  and  that  by  using  the  Microsoft  Excel  spreadsheet  component  available  in 
USARC’s  infrastructure  software  suite,  the  information  could  be  converted  and  imported 
quite  easily  using  OLE  communication  protocols. 
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Another  advantage  of  the  approved  component  framework,  was  that  once 
all  the  required  components  and  interfaces  had  been  specified,  many  of  the  coding 
activities  could  be  performed  in  parallel  as  long  as  the  input  data  necessary  for  the 
component  was  available. 

Once  the  allocations  of  system  requirements  to... software  components  has 
been  made,  parallel... software  definition,  design,  and  implementation 
activities  are  initiated.  During  these  parallel  efforts,  the... development 
team  must  continuously  cooperate  and  communicate  to  ensure  that  their 
implementations  are  compatible.  This  continued  interaction  is  critical  to 
the  successful  integration  of  the.. .software  components.  (USAF-STSC, 

1992,  p.  20). 


b.  ARIES  Coding  Stage 


The  ARIES  U/I  and  application  was  coded  using  the  Visual  Basic  for 
Applications  (VBA)  language  and  standard  structured  programming  techniques.  Only 
one  form  was  created  during  the  Domain  Prototyping  phase  which  contains  all  the  VBA 
objects  and  the  integrated  Mapinfo  object  of  the  ARIES  U/I.  The  rest  of  the  partially- 
compiled  application  is  comprised  of  several  VBA-coded  files  and  one  MapBasic 
program  (Appendix  D): 

•  SUBMAIN.BAS  -  Initializes  the  ARIES  U/I;  Loads  and  connects  COTS 
components  to  U/I;  Displays  the  U/I. 

•  UserInterface.FRM  -  Contains  all  procedures,  business  rules,  and  logic  for 
controlling  the  ARIES  U/I. 

•  PublicDeclarations.BAS  -  A  library  module  that  initializes  all  public  variables 
and  constants;  Contains  the  variables  that  represent  the  SQL  business  rules  for 
calculating  the  ARU-DM  decision  parameters. 

•  Library.BAS  -  A  library  module  that  contains  all  the  procedures  called  by 
other  procedures  more  than  one  time. 

•  OLE  Library.BAS  -  A  library  module  that  contains  all  the  procedures 
supporting  OLE  communications  between  COTS  components. 

•  OLE  Callback.CLS  -  An  object  class  description  necessary  for  commxmicating 
with  the  integrated  Mapinfo  component. 


•  MapBasic.BAS  -  A  library  module  that  initializes  all  public  variables  and 
constants  for  communicating  with  the  integrated  mapping  component. 

•  ARIESArch  -  A  MapBasic  program  that  spatially  selects  the  desired  data 
within  50  miles  of  the  specified  location  and  locates  the  closest  Army  Reserve 
support  facilities. 

Code  evaluation  occurs  during  and  upon  completion  of  coding.  It  ensures 
that  coding  techniques  are  acceptable  and  that  standards  have  been  followed  during  the 
coding  process.  The  evaluation  was  conducted  by  the  development  team  and  NFS 
advisors,  using  peer-review  and  informal  walk-throughs  in  order  to  verify  the  code 
against  the  design,  and  to  ensure  compliance. 

c.  ARIES  SDSS  Application 

The  gain  in  performance  of  this  spatially  enabled  DSS  over  its  manual 
coimterpart  is  formidable.  A  process  that  previously  required  weeks,  can  now  be 
completed  in  minutes.  The  SDSS  DSSA  is  very  flexible  and  offers  numerous  ways  of 
eliciting  preferences  and  displaying  results.  The  structure  is  adaptable  enough  that  it  can 
be  easily  expanded  to  include  additional  decision  parameters,  criteria,  and  improved 
decision  models. 

Given  the  large  number  of  components  that  must  be  centrally  controlled 
by  the  U/I,  and  the  intense  database  activity  involved  in  calculating  decision  parameters, 
a  local  installation  of  the  ARIES  application  at  USARC  Headquarters  was  recommended. 
The  development  team  believed  it  was  critical  to  perform  this  type  of  testing  at  the  actual 
client  site  in  order  to  best  measure  the  application’s  performance  in  an  operating 
environment  that  could  not  be  simulated  at  NFS.  Since  this  was  economically  infeasible, 
the  application  was  rigorously  tested  on  the  provided  laptop  computer,  and  the  burden  of 
network  “beta  testing”  of  ARIES  was  shifted  to  the  USARC  staff. 
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D.  SUMMARY 


Our  experience  in  using  C2C  to  help  US  ARC  develop  the  prototype  and  test  the 
SDSS  concept,  indicates  that  this  approach  can  have  a  major  impact  on  the  way  users  and 
developers  collaborate  on  producing  functional  software.  C2C’s  structural  approach  and 
use  of  component  based  development  techniques  to  incrementally  build  and  deliver 
mission-critical  applications,  formalizes  a  process  that  was,  until  recently,  overly 
complex  and  unwieldy. 

The  C2C  process  puts  an  early  emphasis  on  addressing  a  concept’s  high-risk  areas 
by  rapidly  prototyping  a  proof-of-concept  version  of  the  intended  system  that  defines  its 
specific  component  architecture.  It  does  not  assume  a  fixed  set  of  user  requirements  at 
the  concept  inception,  but  allows  for  iterative  refinement  of  the  requirements  as  the 
project  evolves.  Changes  are  expected  and  accommodated.  The  main  focus  still  remains 
the  final  software  product  and  its  quality,  as  measured  by  the  degree  to  which  it  satisfies 
the  user’s  expectations. 

As  component-based  development  becomes  more  widespread  and  focuses  on 
architecture,  the  complexity  of  the  distributed  operating  environment  should  wane.  Until 
that  occurs,  component-based  systems  built  by  non-programmers  will  probably  continue 
to  be  interconnected  in  an  unstable  “hodge-podge”  fashion.  The  best  way  to  improve  the 
integration  of  these  systems  is  to  adopt  an  enterprise-wide,  integrated  architectural 
strategy  that  incorporates  standards  that  act  to  limit  the  inherent  complexity  faced  by 
users  and  developers.  In  this  sense  C2C  acts  as  a  technological  “gap  filler”  between 
baseline  infrastructure  and  target  applications. 

As  with  any  new  software  development  process  and  modeling  methodology, 
nothing  works  exactly  right  the  first  time  out.  The  USARC-NPS  innovative  collaboration 
was  no  different.  What  appears  to  occur  smoothly  throughout  the  development  of  the 
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ARIES  SDSS  application,  in  retrospect  was  actually  disjointed  and  haphazard  as  USARC 
and  NFS  personnel  underwent  a  “learning  experience”  about  merging  component-based 
technologies  with  architectural  thoughts  and  ideas.  These  “lessons-leamed”  are  what  the 
next  chapter  is  devoted  to  exploring  in  detail. 
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IV.  LESSONS  LEARNED. 


^^There  is  a  point  at  which  methods  devour  themselves.” 

Frantz  Fanon,  Black  Skins,  White  Masks,  1952. 

“/4  tool  knows  exactly  how  it  is  meant  to  be  handled,  while  the  user  of  the  tool  can 
only  have  an  approximate  idea.” 

Milan  Kundera,  1978. 

“Reality  is  the  murder  of  a  beautiful  theory  by  a  gang  of  ugly  facts.” 

Robert  L.  Glass. 

“The  only  thing  new  in  the  world  is  the  history  you  have  not  learned.” 

President  Harry  S.  Truman 


A.  OVERVIEW. 


This  Chapter  examines  some  of  the  most  critical  lessons  that  the  development 
team  learned  while  constructing  the  ARIES  application.  It  is  by  no  means  inclusive  of  all 
the  lessons  learned  during  the  project,  but  rather  a  representative  sample  of  the  lessons 
related  to  component-based  development.  Each  chapter  section  is  presented  in 
categorical  form,  beginning  with  users  and  analysis;  application  development;  rapid 
prototyping,  and  component-based  development.  Each  of  the  pertinent  lessons  related  to 
a  particular  section  is  stated  first  and  then  discussed  at  length. 

B.  CONCEPTUAL  ANALYSIS  AND  THE  USERS. 

•  Because  of  software  developments  inherent  malleability,  it  is  difficult  to 
anticipate  which  requirements  will  be  implemented  easily  and  which  will 
decimate  the  project. 

Deciding  what  to  build  and  what  not  to  build  is  the  age  old  dilemma  that  faces  all 
developers.  Experience  has  proven  that  software  requirements  are  the  biggest 
impediment  to  properly  engineering  complex  systems.  Conventional  as  well  as  state-of- 
the-art  software  development  practices  have  failed  to  make  appreciable  headway  against 
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persistent  and  pervasive  problems  with  requirements  management  (DON-NRL,  1996,  p. 
1).  Beyond  this  need  for  discipline,  requirements  are  intrinsically  hard  to  define  well.  In 
an  attempt  to  better  manage  requirements  analysis,  the  development  team  countered  with 
the  Conceptualization  Phase  of  the  C2C  Heuristic.  By  devoting  crucial  time  and  energy 
at  the  outset,  we  hoped  to  capture,  structure,  and  contain  the  sheer  essence  of  the  project. 
This  could  not  occur  without  an  equal  give-and-take  on  the  part  of  the  intended  users. 
Through  the  formation  of  a  collaborative  effort,  whereby  the  group  built  a  little  and 
prototyped  a  lot,  a  productive  synergy  yielded  stable  requirements  from  which  to  design 
architectures  and  model  the  problem  domain.  The  users  specify  the  “what”  of  the 
problem  and  the  developers  focus  on  the  “how”  of  the  solution.  This  iteratively  and 
multiplicatively  leverages  the  users’  business  knowledge  in  concert  with  the  technical 
acumen  of  the  developers.  Using  prototyping  as  the  practical  solution  The  cognitive 
layers  and  the  feedback  cycle  of  the  C2C  structure  acts  to  progressively  guide  the 
collaborative  ensemble  en  masse  from  high  levels  of  abstraction  to  a  specialized  solution 
space. 

In  the  case  of  ARIES,  the  characterization  stage  and  U/I  prototypes  were  the  most 
instrumental  in  building  the  application  correctly  the  first  time  instead  of  enduring 
endless  cycles  of  change  management.  The  developers  were  able  to  understand  exactly 
what  the  SDSS  needed  to  perform,  were  able  to  communicate  side  issues  and 
discrepancies  in  the  language  of  the  users,  and  used  an  architectural  focus  to  provide  a 
means  for  controlling  the  production  of  the  final  application  (DON-NRL,  1996,  p.  6). 

•  The  developer  cannot  understand  the  business  rules  and  processes  well 
enough. 

Most  application  generation  languages  do  a  good  job  effectively  designing  the 
user  interface  and  providing  the  underlying  support  code  to  connect  the  U/I  to  the 
pertinent  database(s).  But  it  is  the  business  rules  and  data  processing  logic  that  are  the 
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heart  and  soul  of  a  successful  application  and  are  the  most  difficult  to  automate.  It  was 
this  understanding  of  the  rules  to  which  the  NPS  development  team  devoted  a  majority  of 
its  analysis  efforts.  By  focusing  early  in  the  Conceptualization  Phase  on  thoroughly 
comprehending  and  characterizing  the  exact  rules  and  processes  used  by  the  USARC 
decision-makers,  the  team  avoided  extensive  and  unnecessary  rework  later  in  the 
implementation  stages.  Using  process  roadmaps  and  documented  business  rules,  ARIES 
development  became  a  straightforward  exercise  in  prototyping  the  U/I,  identifying  the 
required  SQL  database  operations,  linking  the  Rules  to  the  U/I,  and  linking  the  rules  to 
the  SQL. 

•  Keep  the  user  engaged  in  the  collaborative  process. 

ARIES ’s  intended  users  failed  to  adequately  specify  top  level  system 
requirements  as  quantitatively  as  possible,  and  developers  failed  to  better  elicit  them. 
Too  many  trade-offs  and  design  decisions  were  left  to  the  developer.  Conflict  at 
structured  walk-throughs  occurred  between  the  developer’s  view  of  the  design  and  the 
users’  unarticulated  view.  Large  amounts  of  development  time  were  lost  in  several  C2C 
stages  because  of  these  discrepancies. 

Collaboratively  prototyping  in  one  room  or  meeting  is  difficult  enough  under  the 
best  conditions,  but  in  the  case  of  ARIES  the  development  team  resided  at  NPS  in 
Monterey,  California,  while  a  majority  of  the  time  the  users  were  at  USARC  headquarters 
in  Atlanta,  Georgia.  Attempts  to  regulate  the  collaboration  using  email  proved 
ineffective.  A  second  problem  in  this  arena  involved  the  USARC  LAN  network  software 
upgrade  from  Windows  3.1  to  Windows  NT  which  was  not  scheduled  for  completion 
until  after  product  delivery.  As  a  result,  incremental  prototype  builds  could  only  be 
alpha-tested  by  USARC  decision-makers  during  the  monthly  progress  meetings.  Instead 
of  stabilizing  the  design,  the  opposite  outcome  occurred  as  the  prototype  demonstrations 
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elicited  user  suggestions  not  anticipated  by  the  developers.  For  example,  the  user  wanted 
to  be  able  to  select  the  facilities  for  site  relocation  graphically  using  the  mapping 
component.  The  development  team  mistakenly  assumed  that  the  map  view  should  label 
the  selectable  nodes  with  its  corresponding  facility  identifier  (FacID).  The  Domain 
Prototype  was  built  around  this  misconception,  only  to  discover  at  the  prototype 
demonstration  that  users  had  trouble  “drilling  down”  through  the  map  layers  of  the  map 
view  because  they  were  in  the  habit  of  selecting  facilities  by  the  closest  cities  and  towns 
rather  than  by  FacID. 

•  Identify  who  is  responsible  for  software  maintenance  prior  to  development. 

One  the  biggest  mistakes  that  can  occur  with  regard  to  software  development  is  to 
delay  the  selection  of  the  software  maintenance  organization  until  after  the  development 
of  the  software  application  and  data  structure  has  begun.  The  developer  may  have 
deployed  a  superior  application,  but  if  is  incompatible  with  existing  infrastructures  or 
unsupportable  by  the  recipient  organization’s  IS  support  staff,  then  the  program  probably 
will  not  be  used  and  likely  “wither  on  the  vine”  from  lack  of  support.  The  solution  is  to 
select  the  provider  of  the  technical  support  prior  to  the  commencement  of  application 

development.  The  IS  support  can  be  provided  in  one  of  two  forms: 

•  Externally  by  the  software  development  team/organization,  or . 

•  In-house  or  organically  (i.e.,  by  an  organization  of  the  Army). 

If  an  organic  organization  is  selected,  then  the  software  tools  and  applications 
used  for  development  must  be  provided  to,  and  agreed  upon,  by  the  maintenance 
organization.  In  the  case  of  ARIES,  the  initial  Analysis  Prototypes  were  developed  using 
Borland’s  Delphi  2.0  fourth  generation  language.  Although  the  lead  developer  had 
experience  with  Delphi  client-server  environments,  the  US  ARC  IS  Staff  were 
inexperienced  and  imfamiliar  with  the  Delphi  programming  enviromnent.  Therefore 
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Delphi  was  summarily  vetoed  by  the  US  ARC  IS  Staff  and  two  additional  requirements 

were  imposed  in  the  second  round  of  the  Conceptualization  Phase: 

•  Both  the  ARIES  Application  and  Administer  must  be  developed  in  Microsoft 
Visual  Basic  4.0. 

•  All  Visual  Basic  and  MapBasic  source  code  must  be  provided  separately  to 
USARC  in  an  uncompiled  form. 

This  resulted  in  a  six  week  loss  of  development  time  while  the  development  team 
attended  several  professional  Visual  Basic  workshops  and  redesigned  the  Analysis 
Prototype  to  comply  with  these  new  requirements. 

C.  ARIES  APPLICATION  DEVELOPMENT  LESSONS. 

•  Small  development  teams  are  best. 

It  is  a  fundamentally  simple  principle  that  if  you  want  to  limit  the  number  of 
defects  in  a  project,  then  limit  the  number  of  developers  involved  in  producing  the 
project.  Good  people  produce  good  software  (Yourdon,  1996,  p.  28).  The  results  from 
using  a  small  team  for  the  ARIES  SDSS  were  better  management,  less  coordination,  and 
improved  communication  between  both  team  members  and  users.  By  using  a  design 
heuristic,  automated  tools,  and  architectural  structure,  the  development  team  was  able  to 
remain  small  in  size  (3-8  members),  and  reducing  the  amount  of  code  to  be  written  and 
tested.  Small  teams  using  modem  tools,  techniques,  and  user  experience  can  achieve 
high  levels  of  productivity. 

•  Spatial  selection,  when  properly  implemented,  can  substantially  reduce 
decision  model  parameter  calculation  response  times. 

During  the  Visualization  Phase,  the  domain  prototype  of  the  ARIES  SDSS 
performed  much  more  slowly  than  the  collaborative  team  had  anticipated.  Some  of  the 
problems  occurred  because  of  overhead  from  complex  SQL  queries  between  the  U/I  and 
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the  RDBMS.  For  example,  calculating  the  available  MOS’s  from  the  closing  Army 
Reserve  units  requires  the  following  logic: 

Determine  all  the  individuals  assigned  to  Closing  Units  who  live  within 

50  miles  of  the  Proposed  Site  having  MOS’s  matching  a  prospective 

Moving  Unit’s  requirement  for  a  particular  MOS. 

The  example  took  nearly  an  hour  to  execute  on  a  Pentium  120  MHz  computer, 
regardless  of  the  population  density  of  the  location.  Even  with  performance  tuning 
execution  time  was  still  about  40  minutes  on  average  to  perform  the  query.  The  solution 
was  to  utilize  the  specialized  geographic  processing  capability  of  the  Mapinfo  component 
to  spatially  select  only  the  database  records  within  the  50  mile  geographic  boundary  of 
the  proposed  site.  This  required  obtaining  a  waiver  from  USARC  to  allow  the 
development  team  to  geocode  the  Army  Reserve  Unit  personnel  database  (G18CWE) 
using  the  MARS  Engine,  to  migrate  the  database,  and  to  spatially  enhance  it  and  two 
others  for  geoquerying  by  ARIES.  The  performance  gain  from  this  technique  was  on  the 
order  of  five  to  seven  times  faster  (Figure  5-1). 

•  Avoid  design  error  propagation  by  adhering  to  a  philosophy  of  “Daily  Build 
and  Smoke  Test.  ” 

When  discussing  software  development  in  terms  of  incremental  prototypes  or 
iterative  “builds,”  one  thinks  of  monthly  or  weekly  milestones.  This  correlates  to  the 
business  world  and  our  daily  lives  as  a  “normal”  production  pattern.  The  trouble  lies  in 
the  rapid  changes  that  prototyping  perpetuates;  factor  in  concurrent  development  by  team 
members,  and  you  have  a  recipe  for  disaster  when  project  assembly  occurs  in  one  month 
(e.g.,  “let’s  put  it  together  and  see  what  works”). 
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Figure  4-1.  Spatial  Solution  Diagram. 


Component-based  development  allows  the  developer  to  follow  a  different 
approach  —  the  Daily  Build  and  Smoke  Test.  This  process  can  be  used  effectively  for 
projects  of  any  size  or  complexity  and  consists  of  developers,  on  a  daily  basis 
assembling,  compiling,  linking,  building,  etc.,  all  the  project  components  and  code 
modules  into  a  deliverable  application  and  then  testing  to  verify  its  basic  operations.  The 
team  is  not  allowed  to  continue  coding  until  the  current  “build”  passes  satisfactorily,  and 
component  failures  can  be  attributed  as  the  responsibility  of  the  component  creator.  In 
this  manner  the  developers  start  every  day  with  a  product  that  functions  correctly,  and 
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ensures  that  any  defects  that  are  present  were  induced  within  the  last  24  hours.  It  is  far 
easier  to  retrace  an  individual’s  one  day  effort,  than  a  team’s  monthly  effort.  This 
prevents  developers  from  unwittingly  developing  incompatible  components  and 
corrupting  the  overall  design. 

Why  is  this  so  important?  The  process  pays  for  itself  by  reducing  the  time- 
consuming  development  risks  of  low  quality,  integration  failure,  and  poor  progress 
visibility  (McConnell,  1996,  p.  405).  Not  only  does  the  developer  always  have  a 
deployable  application,  but  the  users,  project  managers,  and  other  team  members  always 
have  a  daily  status  of  what  is  complete  and  what  needs  to  be  added.  Any  problems  which 
arise  tend  to  be  relatively  small  in  nature  and  can  be  dealt  with  accordingly,  rather  than 
shifting  into  “crisis  mode”  to  rework  code  following  a  monthly  or  quarterly  project  build. 
“The  daily  build  is  the  heartbeat  of  the  project.  It’s  how  you  know  you’re  alive” 
(McCarthy,  1995). 

•  A  strong,  stable,  and  well-defined  architecture  prevents  degeneration  of 
design. 

It  can  be  extremely  difficult  to  maintain  an  application  architecture  as  the 
development  process  unfolds.  Over  time,  performance  and  delivery  pressures  can 
combine  to  blur  the  architectural  design,  resulting  in  unwanted  degeneration  of  the 
structure  at  all  levels.  A  “good  enough”  architecture  may  be  the  result  of  attempting  to 
accommodate  a  given  COTS  component  structure,  but  a  standards-based  architecture  is 
critical  to  the  development  process.  Quality  architecture  is  more  likely  to  influence  a 
successful  project  than  a  given  set  of  components.  Component  technology  and  good 
architecture  need  to  be  intrinsically  related,  otherwise  architectural  mismatch  can  occur 
(Garlan  et.  al.,  1995,  p.  18).  Rapid  prototyping  can  accelerate  this  mismatch  unless  a 
strict  development  discipline  is  enforced  by  the  developers  to  rework  and  revisit  all 
affected  components  after  each  prototyping  cycle  ends  and  during  component  integration. 
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A  well-thought  out  architectural  solution  can  be  effectively  and  efficiently  implemented 
in  almost  any  language,  environment,  and  infrastructure. 

D.  RAPID  PROTOTYPING  LESSONS. 

•  Decide  up  front  whether  the  prototype  is  to  be  a  “throwaway”  or  a  full 
production  system. 

A  throwaway  prototype  or  scaled-down  model  is  used  for  feasibility  exploration 
and  proof-of-concept  studies  in  which  user  requirements  are  incomplete  and  the  system 
approach  is  uncertain.  However,  if  a  prototype  is  being  constructed  using  known 
requirements,  and  only  minor  uncertainties  remain  regarding  the  system  approach,  then 
an  evolutionary  prototype  can  be  built,  in  which  some  or  all  of  the  prototype  is  retained 
(Gordon  and  Bieman,  1995,  pp.  85-86).  Usually  the  throwaway  is  built  first,  with  the 
developer  proceeding  quite  rapidly  as  the  user  requirements  are  defined  and  the  system 
architecture  is  confirmed.  The  downside  is  that,  in  its  limited,  scaled-down  form,  the 
prototype  is  usually  incapable  of  being  deployed  as  a  fiill  production  system  because  so 
many  shortcuts  have  been  taken  to  illustrate  whether  something  could  be  done.  When  the 
design  specifications  are  complete,  then  it  can  be  rewritten  to  fulfill  a  more  flexible, 
scaleable,  and  extensible  form. 

Originally  ARIES  was  budgeted  for  a  two-phased  development:  a  stand-alone 
throwaway  prototype,  and  a  full  production  network-centric  version.  The  network  model 
was  to  be  a  three-tiered,  fully  object-oriented  client-server  application  that  would  be 
Windows  NT  enhanced  to  maximize  decision  parameter  calculation  using  remote  OLE 
automation.  Difficulties  with  this  scheduled  arrangement  occurred  when  project  funding 
was  reprogrammed  halfway  through  the  C2C  development  cycle.  This  required  a 
collaborative  reorganization  of  the  ARIES  SDSS  to  enable  the  application  to  execute  in 
the  network  environment  without  being  optimized  for  it. 
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Conventional  wisdom  counsels  that  whether  “[you]  plan  to  throw  one  away;  you 
will  anyway,”  (Brooks,  1 987)  but  often,  in  the  interests  of  time  and  expense,  a  prototype 
will  be  retained  in  some  form  from  the  start.  As  developers  we  are  not  advocating  one 
particular  method  over  another,  only  that  in  the  best  interests  of  the  collaborative  design 
team,  it  is  imperative  to  decide  from  the  outset  which  one  it  will  be. 

•  The  collaborative  nature  of  prototyping  requires  more  of  the  user's  time 
than  he  plans  for. 

The  challenge  of  managing  a  prototyping  effort  can  be  much  more  complicated 
than  managing  conventional  software  development.  The  difference  stems  from  the  heavy 
emphasis  placed  on  providing  the  users  what  they  want  and  need.  This  leads  to  modeling 
processes  in  new  ways,  which  in  turn  requires  near  constant  feedback  to  prevent  wasted 
effort  and  trivial  pursuits  of  unintended  features.  Sometimes  this  constitutes  more 
feedback  than  the  user  is  capable  of  providing. 

Because  US  ARC  could  only  review  U/I  prototype  once  a  month  during  their  trips 
to  NFS,  user  feedback  tended  to  come  very  late  in  the  prototyping  cycle.  This  latency 
meant  constructive  feedback  came  at  a  time  when  incorporating  the  changes  incurred 
significantly  higher  costs.  Changes  in  the  user  interface  prototype  at  the  end  of  each 
Visualization  Phase  walk-through  twice  resulted  in  an  additional  four  weeks  of  design, 
testing,  and  unit  integration. 

•  Quick  visual  results  encourages  the  user(s)  to  suddenly  see  possibilities 
where  before  they  had  only  seen  barriers. 

A  striking  phenomenon  about  visually-oriented  prototypes  is  the  imcanny  ability 
to  elicit  Archimede’s  “Eureka!”  reactions  from  the  pool  of  intended  users.  The  potential 
end-user  goes  from  a  position  of  “I’ll  know  it  when  I  see  it,”  to  “if  you  can  do  that,  then 
surely  you  should  be  able  to  do  this?”  It  provides  a  sense  of  empowerment  to  the  user 
and  allows  him  to  shape  and  envision  the  final  system..  In  practice  however,  this  can  only 
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occur  after  he  has  gained  some  experience  from  the  system  proposed  by  the  developers 
(Gordon  and  Bieman,  1995,  p.  86).  As  with  every  new  unprecedented  capability,  there 
comes  a  dark  side.  The  user’s  hunger  for  more  and  more  functionality  can  become 
insatiable  without  some  outside  restraint  imposed  by  the  development  team.  This  may 
result  in  uncontrolled  “requirements  creep.”  Because  the  prototype  can  so  effectively  and 
easily  mirror  the  final  system,  the  intended  user(s)  may  have  little  sense  of  the  relative 
costs  and  the  diminishing  marginal  returns  of  adding  functionality  beyond  the  scope  of 
the  initial  concept.  In  short,  “perfection”  becomes  the  enemy  of  “good-enough.” 

In  this  sense  it  is  the  duty  of  the  developers  to  guide  and  assist  the  users  in 
prototyping  the  final  system  around  a  reasonable  bandwidth  of  the  users’  stated  goals. 
Their  experience  and  objectivity  are  critical  in  knowing  when  to  stop  prototyping  and 
start  coding.  Otherwise  excessive  gold  plating  may  result  in  a  great  system  that  never 
gets  built. 

•  Using  COTS  products  does  not  eliminate  software  maintenance. 

On  the  contrary,  because  the  origin  of  installed  components  is  external  to  the 
developers,  software  maintenance  plays  an  even  larger  role  than  it  does  in  conventional 
software  product  development.  If  a  component  is  modified  and  the  vendor  releases  a 
bigger  and  better  version,  as  they  always  do,  who  then  is  responsible  for  the  care  and 
feeding  of  the  application?  The  vendor?  The  development  team?  The  recipient 
organization?  Secondly,  if  the  developers  use  the  product  “as-is”  and  the  vendor  updates 
other  components  in  the  application  architecture,  who  bears  the  brunt  of  the  burden  to 
ensure  component  compatibility?  Each  change  in  the  implemented  design  requires  a  new 
version  of  the  system  to  maintain  the  technical  integrity  of  the  application.  Otherwise  the 
incompatibilities  become  cumulative  and  propagate  instability  throughout  the  component 
architecture. 
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This  was  the  case  with  LDW,  the  ARIES  DSS  component.  As  the  other 
components  received  major  product  upgrades,  including  the  operating  system,  the  LDW 
DSS  remained  unchanged.  Because  of  the  unwillingness  of  the  LDW  vendor  to  migrate 
LDW  to  a  32-bit  application,  the  burden  of  maintaining  the  ARIES  product  over  the  next 
18  months  will  become  even  more  difficult  without  radical  work-arounds  to  make  a  16- 
bit  program  backwards  compatible  within  a  32-bit  component  framework.  As  a  result, 
the  viability  of  ARIES  will  become  less  and  less  certain  as  US  ARC  upgrades  its 
infrastructure. 

In  summary,  you  cannot  simply  build  a  component-based  application  and  then 
forget  about  it.  The  more  easily  such  an  application  is  built,  the  more  critical  the 
maintenance  effort  needed  over  the  application’s  lifecycle. 

E.  COMPONENT-BASED  COMPUTING  LESSONS. 

•  Building  custom  components  is  really,  really,  hard. 

Do  not  be  fooled  by  the  component  evangelists.  It  is  very  difficult  and  time 
consuming  to  build  even  simple  components  that  work  and  commimicate  well  with  other 
components  and  applications  let  alone  complex  ones.  In  today’s  dynamically  complex 
event-based  development  environments,  a  developer  must  be  able  to  anticipate  every 
possible  use  and  interaction  a  component  could  be  expected  to  fulfill  and  imdergo 
respectively.  Many  component  building  and  application  software  packages  have  been 
created  to  address  these  issues,  but  testing  components  in  infinitely  diverse  combinations 
is  a  Herculean  undertaking.  Further,  using  contemporary  methodologies  does  not  insure 
success;  many  dismally  poor  components  have  been  produced  using  modem  tools  and 
techniques.  High  quality  and  reliability  comes  at  a  premium  cost.  It  is  far  easier  to  buy 
and  modify  a  well-designed  COTS  product  than  to  develop  and  validate  a  custom  built 
one.  The  challenge  in  doing  this  well  is  to  know  and  understand  thoroughly  the  available 
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off  the  shelf  commercial  products,  because  many  of  the  problems  encountered  during 
implementation  simply  cannot  be  determined  before  integration  begins. 

•  The  learning  curve  for  mastering  component-based  application  development 
is  steep. 

It  is  important  that,  prior  to  using  a  particular  component  or  fourth  generation 
development  language  for  developing  a  component-oriented  application,  the  developers 
are  comfortable  and  familiar  with  the  product.  One  person  cannot  be  expected  to 
instantly  master  several  different  components  well  enough  to  be  an  effective  and  efficient 
developer  while  at  the  same  time  attempting  to  prototype  the  system.  “Just  in  time 
learning”  is  insufficient  to  guarantee  a  stable  design  and  is  often  a  blueprint  for  disaster. 

•  Component  communication  protocols  are  the  weakest  link  in  the 
development  chain. 

Some  components  are  capable  of  using  open  or  de  facto  standards  (e.g.,  OLE), 
some  must  utilize  proprietary  communication  protocols  (e.g.,  DDE),  and  others  cannot 
operate  with  various  components  at  all.  In  order  to  effectively  implement  the  ARIES 
component  framework,  the  developers  were  forced  to  use  a  combination  of  all  three 
methods  to  achieve  the  desired  functionality.  This  approach  was  not  without  its 
drawbacks,  for  the  less  ‘open’  the  protocol,  the  less  functional  the  implementation.  For 
example,  because  LDW  is  incapable  of  importing  most  current  file  formats,  Microsoft 
Excel  had  to  be  used  to  save  the  resultant  scenario’s  decision  parameter  matrix  in  a  tab- 
delimited  format  that  LDW  could  process;  Visual  Basic  could  not  do  that  easily.  This 
introduced  another  component  in  the  architecture  whose  only  function  was  to  serve  as  a 
file  transfer  agent,  a  function  which  is  not  the  component’s  strongest  suit. 

The  Mapinfo  component,  on  the  other  hand,  fully  embraces  the  de  facto  OLE 
standard  and  effectively  documents  the  component’s  interconnections.  As  a  result, 
approximately  ninety  percent  of  the  functionality  within  the  Mapinfo  application  could  be 
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done  within  an  integrated  map  window.  To  similarly  manipulate  the  LDW  application, 
the  ARIES  U/I  hypnotized  it  into  executing  user-simulated  keyboard  commands  using 
Microsoft  Windows  API  routines  and  macro  scripts.  Essentially  the  ARIES  U/I  tricked 
the  program  into  thinking  a  user  was  present  when  he  was  not.  This  technique  is  strictly 
limited  in  that  only  about  20%  of  LDW’s  capability  could  be  controlled  in  this  way  by 
ARIES. 

•  Use  of  Commercial-Off-The-Shelf  (COTS)  components  can  result  in  “dead 
code  ”  solutions. 

In  some  cases  the  use  of  an  appropriate  or  inappropriate  component  can  result  in 
some  or  most  of  the  component’s  functionality  not  being  used  (dead  code).  Essentially  a 
large  component  with  many  capabilities  may  only  be  needed  to  provide  a  single  function 
or  a  small  subset  of  the  original  functionality.  An  example  of  this  is  the  use  of  Microsoft 
Excel,  a  large  and  complex  application  for  spreadsheet  manipulations,  which  is  used 
exclusively  in  ARIES  to  load  the  decision  parameter  matrix  and  save  it  in  a  different 
format.  Similarly,  Mapinfo  is  used  only  for  geoquerying  and  facility  selection,  in  spite  of 
its  extensive  thematic  mapping  capability.  The  resources  that  the  mapping  component 
consumes  (e.g.,  4  MB  of  random-access  memory)  are  lost  to  other  applications  when  only 
15%  of  the  component  is  used. 

•  COTS  components  are  not  all  “open” standard  compliant 

This  was  probably  the  hardest  lesson  the  ARIES  development  team  had  to 
contend  with,  and  is  a  major  issue  for  anyone  interested  in  pursuing  component-based 
development  as  a  solution  provider.  In  the  past  components  or  small,  specialized  16-bit 
applications  were  designed  and  built  using  proprietary  standards  combined  with 
programmers’  idiosyncratic  methods  to  achieve  a  certain  level  of  performance.  As 
operating  systems  have  matured  and  become  more  sophisticated,  components  and 
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programs  are  able  to  take  advantage  of  object  libraries  and  infrastructure  to  achieve 
functionality.  Yet  openness  is  still  measured  by  proprietary  designs  and  consumer 
acceptance.  Providing  a  uniformly  understandable  means  for  accomplishing  tasks  is  key 
to  limiting  communication  chaos  and  reducing  risk  within  the  application’s  architecture. 
Without  standardization  and  architecture,  the  process  of  integrating  unique  application 
components  becomes  extraordinarily  complex.  Since  no  single  vendor  has 
accommodated  the  entire  range  of  infrastructure  management  needs,  de  facto  standards 
have  emerged. 

This  is  where  the  real  trouble  arises,  for  third-party  components  and  updates  from 
vendors  are  not  exactly  ‘plug  and  play’,  and  frequently  have  a  tendency  to  be  falsely 
documented.  The  integration  of  various  component  data  formats  and  communication 
protocols  can  be  very  complex,  and  subtle  “gotchas”  within  a  component  may  render  its 
role  in  the  component  framework  null  and  void.  Initially  the  development  team  tried  to 
grab  too  much  “off  the  shelf’  and  hastily  put  it  all  together  during  the  prototyping  stages. 
This  yielded  mixed  results  —  mostly  bad.  The  team  was  so  enamored  by  the  prospect  of 
a  buy-and-integrate  strategy  that  it  failed  to  realize  that  some  COTS  products  can  only 
interact  in  accordance  with  its  own  set  of  standards,  architectures,  and  design.  Not  all 
COTS  products  are  universally  pliable.  They  may  require  in  depth  analysis  of  their 
intended  operating  environments  and  structure. 

As  an  example,  LDW  is  capable  of  screen  capturing  its  various  graphic  analysis 
displays  to  the  clipboard  or  a  graphic  file.  The  undocumented  difficulty  is  that  the 
“clipboard”  was  implemented  by  the  programmer  in  C++  without  using  Windows  native 
API  routines.  Additionally,  the  graphic  file  is  the  16-bit  Windows  meta-file  standard 
(WMF)  that  is  supported  by  only  a  handful  of  programs  (e.g.,  Microsoft  PowerPoint). 
Therefore,  the  only  method  available  to  allow  the  user  to  personalize  the  standard  reports 
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feature  of  the  ARIES  U/I  was  to  implement  another  large  “dead-code”  component,  like 
PowerPoint,  to  once  again  act  as  a  file  transfer  agent  for  graphic  analysis  editing. 

Another  difficulty  emerges  when  trying  to  integrate  new  versions  of  existing 
components  within  the  application’s  architecture.  The  new  version  may  have  a  different 
look-and-feel  and  require  more  memory,  and/or  previous  data  formats  and  protocols  may 
no  longer  be  supported.  In  any  case,  another  C2C  incremental  cycle  will  need  to  be 
completed  to  ensure  application  compliance  and  functionality. 

The  only  way  in  which  to  make  various  disparate  components  operate  together 
reliably  is  to  adopt  a  strong  single  vendor  infrastructure  solution  (Microsoft)  and  work 
within  the  confines  and  limitations  inherent  to  the  selected  standards  and  architecture. 
Hopefully  in  the  future,  emerging  software  technologies  will  be  developed  and  distributed 
as  a  new  kind  of  component.  A  component  that  is  functionally  cohesive,  based  upon 
open  standards,  small  in  terms  of  complexity,  and  therefore  capable  of  operating  in 
conjunction  with  all  other  possible  components  and  software  applications.  (Figure  5-2). 

F.  SUMMARY. 

It  is  becoming  increasingly  clear  that  software  development,  which  relies  heavily 
upon  component-based  architecture,  requires  modifications  to  the  traditional  development 
methodologies.  Although  some  of  the  lessons  derived  from  ARIES  were  recurring 
themes  of  software  developments  lessons  of  the  past  recast  in  component-beised  form, 
others  were  unique  to  the  particular  technologies  and  methods  used  within  the  structured 
C2C  paradigm.  In  the  final  chapter,  we  summarize  the  lessons  learned  from  this  SDSS 
exercise,  and  project  how  these  can  be  adapted  to  future  component-based  development 
applications. 
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Figure  4-2.  Component  Evolution  Diagram. 
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V.  CONCLUSIONS  AND  FUTURE  RECOMMENDATIONS. 


^'Institutionalizing  organization-wide  decision-making  processes  and  an 
architecture  is  the  key  to  all  of  our  information  system  development  efforts... and 
our  primary  measure  of  success  is  impact  on  the  bottom  line.” 

Chief  Information  Officer  (GAO,  1994). 

“It  is  generally  very  difficult  to  keep  up  with  a  field  that  is  economically 
profitable,  and  it  is  only  natural  to  expect  that  many  of  the  techniques  described 
here  will  eventually  be  superseded  by  better  ones.” 

Donald  E.  Knuth,  The  Art  of  Computer  programming,  1973. 

“We  build  systems  like  the  Wright  brothers  built  airplanes  —  build  the  whole 
thing,  push  it  off  a  cliff,  let  it  crash,  and  start  over  again.” 

Professor  R.  M.  Graham,  Software  Engineering,  1969. 


A.  INTRODUCTION. 


This  chapter  synopses  the  underlying  themes  characterizing  the  development  and 
implementation  of  the  ARIES  SDSS.  It  summarizes  our  experience  with  using  the 
Concept-to-Code  (C2C)  design  heuristic  to  construct  software  within  the  context  of  a  new 
structured  paradigm,  and  provides  suggestions  and  insight  into  the  ARIES  Next 
Generation  (NEXGEN)  prototypes. 

B.  LOOKING  BACK. 

Reflection  upon  the  ARIES  SDSS  implementation  could  be  perceived  in  one  of 
two  ways:  as  “blind  luck”,  a  one-time-success  story  that  by  sheer  happenstance  delivered 
exactly  what  the  user  wanted  with  a  development  team  that  had  no  prior  experience  with 
the  underlying  development  tools;  or,  in  a  more  realistic  light,  as  an  application  which 
provided  a  means  to  explore,  justify,  and  demonstrate  the  validity  of  using  component- 
based  computing  in  conjunction  with  rapid  application  development  techniques,  to 
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quickly  and  accurately  produce  a  scaleable,  extensible,  and  useful  decision  support 
application. 

The  C2C  design  heuristic  employed  for  ARIES  allowed  the  collaborative  team  to 
quickly  conceive  and  sketch  screens  and  displays,  and  then  build  the  user  interface  up 
front  in  a  short  turnaround  period.  Defining  how  the  components  of  the  application 
architecture  were  to  communicate  with  one  another,  drove  how  the  intended  functionality 
of  the  architecture  was  to  be  accomplished.  The  heuristic  allowed  the  developers  to 
“architect”  the  system  into  small  components  and  put  the  high  risk  segments  (e.g., 
primary  functionality)  at  the  head  of  the  prototyping  line,  rather  letting  them  slip  to  the 
end.  It  was  important  to  build  the  most  difficult  components  first  and  then  add  the  “nice- 
to-haves”  later  on.  C2C  also  greatly  improved  management  oversight  by  allowing  the 
application  development  process  to  be  layered  from  a  generic  concept  to  specialized 
solution. 

In  summary,  the  C2C  process  has  resulted  in  a  number  of  benefits: 

•  Facilitated  understanding  of  the  development  process  by  managers  and 
programmers  using  a  one-page  graphical  representation. 

•  Provided  concise,  definable  phases  with  clear  entry  and  exit  criteria  and 
staged  iterative  development. 

•  Fostered  an  atmosphere  of  continuous  quality  process  improvement  between 
users  and  developers. 

•  Allowed  small  development  teams  to  implement  large  scale,  complex 
applications  in  short  development  cycles. 

•  Provided  clear  communication  of  project  status  between  the  development 
team  and  management  on  a  daily  basis. 

The  success  of  the  ARIES  SDSS  could  be  considered  surprising,  but  in  reality  it 
was  no  fluke.  The  C2C  process,  applied  carefully,  can  lead  to  powerful  applications 
within  a  surprisingly  short  period  of  time,  months  vis-a-vis  years  as  in  the  case  of  ARIES. 
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Undoubtedly,  C2C  will  continue  to  undergo  experimental  refinement  and  improvement, 
as  it  may  very  well  become  the  mainstay  of  software  application  development. 

To  date,  the  ARIES  SDSS  is  effectively  deployed  on  the  USARC  local  area 
network,  as  well  as  USARC  staff  officers’  laptop  computers.  The  results  of  the  ARIES 
SDSS  deployment  have  been  very  positive  for  both  the  NFS  development  team  members 
and  the  USARC  staff.  The  issues  of  timely  and  consistent  response  to  site  relocation 
questions  appear  to  be  more  than  adequately  met  by  the  ARIES  SDSS  prototype. 

C.  LOOKING  FORWARD. 

1.  Current  Technology  Options. 

a.  Infrastructure:  A  Component  Update 

In  the  short  time  since  the  deployment  of  the  ARIES  SDSS  prototype  on 
the  USARC  LAN,  several  changes  have  occurred  with  its  primary  components.  All  of 
the  COTS  infrastructure  components,  with  the  exception  of  Logical  Decisions  for 
Windows,  have  had  new  versions  released  by  their  associated  vendors.  Each 
component’s  functionality  has  been  greatly  enhanced  and  conforms  to  widely  accepted 
client-server  protocols.  This  includes  the  Visual  Basic  development  language,  which  has 
been  significantly  upgraded  to  function  exclusively  within  the  component-based 
paradigm.  Applications  created  in  Visual  Basic  5.0  are  now  fully  compilable  and  the 
ODBC  component  has  been  integrated  into  the  new  JET  SQL  3.5  RDBMS  engine.  If 
ARIES  code  were  migrated  unchanged  to  the  new  4GL  environment,  the  user  could 
expect  to  see  an  approximate  20%  increase  in  program  execution  time  and  a  dramatic 
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increase  in  non-native  data  processing  time.  This  would  also  greatly  reduce  the  time 
required  to  build  the  data  migration  warehouse  from  USARC’s  FoxPro  2.0  data  sources. 

Mapinfo  and  MapBasic  have  also  been  improved,  however,  the  vendor  has 
also  created  a  separate  integrated  mapping  component,  called  MapX,  based  on  the 
Microsoft  ActiveX  standard.  MapX  allows  developers  to  directly  compile  the  desired 
mapping  functionality  with  the  prototyped  application,  thus  eliminating  the  need  for  OLE 
communications  between  the  two  components.  The  integrated  mapping  features  can  now 
be  “hardwired”  directly  into  the  ARIES  U/I  and  would  only  need  a  fourth  of  the 
computer  memory  currently  used  by  the  Mapinfo  application. 

b.  ARIES  DSS  Component  Redesign:  The  Need  for  Innovation 

The  current  version  of  LDW  in  its  16-bit  format,  is  still  more  than  capable 
of  providing  the  required  functionality,  but  as  US  ARC  upgrades  its  IT  infrastructure  to 
take  advantage  of  future  technology,  the  ARIES  DSS  component  in  its  unscalable  form, 
will  eventually  fail  to  provide  effective  decision  support.  What  is  needed  is  a  new 
scaleable  and  extensible  32-bit  DSS  component.  Currently,  there  are  no  vendors 
marketing  DSS  software  with  all  of  the  functionality  of  the  16-bit  LDW  application  (e.g., 
automatic  waiting,  dynamic  sensitivity,  etc.)  The  difficult  choice  is  to  either  wait  for 
market  conditions  to  change,  or  custom  develop  a  similar  DSS  component  with  the 
following  additional  features: 

•  Allow  the  decision  model  to  be  directly  manipulated  within  an  integrated 
window  on  the  ARIES  U/I. 

•  Allow  decision-makers  to  graphically  add  or  delete  new  decision  parameter 
nodes,  as  well  as  fully  document  how  they  are  calculated. 

•  Create  a  Report  Manager  that  allows  the  user  to  drag-and-drop  various 
decision  model  graphs  into  standard  documents  (e.g.,  Microsoft  Word, 
HTML,  etc.) 


84 


c. 


Migrate  Decision  Making  to  the  Web 


In  order  to  take  advantage  of  USARC’s  upgraded  Windows  NT  operating 
system  and  the  continued  focus  on  network-centric  infrastructure;  the  competent 
developer  can  use  the  Visual  Basic  5.0  component  creation  tool  to  build  a  new  ARIES 
component  that  separates  the  US  ARC  business  rules  and  decision  parameter  calculations 
from  the  user  interface.  By  using  ActiveX  technology,  the  ARIES  SDSS  can  truly  be  a 
three-tier  client-server  application.  The  rules  and  processes  could  be  changed,  updated, 
or  added  separately  from  the  ARIES  U/I  while  still  in  accordance  with  corresponding 
changes  in  the  ARU-Decision  Model.  Development  time  can  now  be  better  spent 
elsewhere  instead  of  redesigning  the  U/I  every  time  a  business  rule  or  condition  changes. 

The  new  Visual  Basic  development  language  also  allows  the  developer  to 
“web-enable”  any  application  quickly  and  easily  from  within  the  4GL  environment.  The 
ARIES  U/I  could  now  be  rapidly  prototyped  within  a  common  development  environment 
by  the  collaborative  team  in  less  time,  using  a  web  browser  (e.g.,  Netscape  Navigator  or 
Microsoft  Explorer)  and  a  point-and-click  web  page  designer  (e.g.,  Adobe  PageMill  or 
NetFusion).  This  would  allow  ARIES  to  use  more  of  USARC’s  stabilized  infrastructure, 
reduce  the  amount  of  software  maintenance  support  needed,  and  reduce  the  number  of 
languages  and  development  tools  that  the  application  developer  must  learn. 

2.  Future  Technology  Options. 

An  important  concern  is  how  far  the  process  of  simplification  of  the  user  interfaee 
should  go  to  provide  easy  access  to  spatial  information  without  sacrificing  necessary 
functionality.  Prototyped  software  that  enables  site  selection  across  space  and  time  using 
a  component-based  infrastructure  like  the  ARIES  SDSS,  has  been  created  as  one  small 
step  towards  the  continued  development  of  spatial  decision  support  systems.  Thanks  to 
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new  component-based  software  tools,  it  is  now  possible  to  create  compact,  yet 
specialized  web-based  applications  that  allow  inexperienced  users  to  participate  to  a 
greater  extent  in  solving  local,  spatially  oriented  problems  as  decision-makers  rather  than 
as  programmers.  This  is  all  desirable  as  far  as  it  goes,  but  without  changes  to  other 
peripheral  issues,  the  future  capabilities  of  the  ARIES  NEXGEN  can  only  advance  so  far. 
The  US  ARC  business  processes  related  to  site  selection  decisions  are  ripe  for  a 
concentrated  reengineering  effort  that  has  the  future  in  mind  —  Visioneering. 

a.  Data  Source  Management 

The  underlying  data  management  philosophy  of  the  NEXGEN  SDSS  is 
that  the  entire  US  ARC  network,  local  and  remote  sites,  comprise  a  single,  large  virtual 
“Resources-to-Readiness”  data  migration  warehouse.  The  decision-maker  should  be  able 
to  access  any  and  every  data  source  relating  to  site  selection  whether  on  an  Army  Reserve 
mainframe  in  Washington  D.C.,  or  a  spatial  data  server  on  the  local  LAN;  all  from  within 
the  browser  U/I.  In  today’s  network-centric  ecosystem,  it  makes  good  sense  to  use  the 
web  as  an  operating  desktop  since  it  is  a  logical  interface  that  most  users  can  quickly 
learn  and  understand.  Essentially,  the  NEXGEN  is  a  network  user  interface  (NUI), 
whereby  the  user  is  able  to  seamlessly  apply  business  rules  and  calculate  decision 
parameters  without  having  to  have  knowledge  of  where  the  data  actually  resides. 

The  NUI  will  improve  database  processing  by  leveraging  the  flexibility  of 
the  web  middleware  to  pull  data  simultaneously  from  all  local  and  mainframe  data  stores 
using  open  standards.  In  short,  web-based  technologies  act  as  a  “data  resolver”  to 
coimect  decision-makers  to  information  no  matter  where  it  is  stored  or  how  it  is 
structured  (Joch,  1997,  p.  104D). 
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b. 


Decision-Maker  Knowledge  Management 


In  order  to  adapt  to  the  continuous  turnover  of  military  personnel  at 
USARC  headquarters,  the  NEXGEN  SDSS  needs  to  be  able  to  interactively  model  and 
capture  the  corporate  knowledge  about  various  data  sources,  business  rules,  and  ad-hoc 
queries  residing  in  the  minds  of  the  decision-makers.  When  stored  and  replicated,  this 
meta-data  knowledge  becomes  a  reusable  resource  that  ensures  a  given  decision  analysis 
can  be  based  on  repeatable  findings.  In  short,  this  means  knowledge  management 
through  automation. 


c.  Decision  Parameter  Derivation  in  Parallel 

Although  new  technologies  and  software  are  produced  everyday,  the 
appetite  for  higher  application  performance  is  never  satiated.  The  sequential  calculation 
of  ARIES  decision  parameters  using  spatial  selection  was  a  superior  solution  for  mobile 
decision-makers,  but  within  the  NT  ecosystem,  parallelism  is  an  even  better  solution. 
The  NT  network  supports  this  by  near  simultaneous  launching  of  remote  automated  OLE 
server  objects  for  decision  parameter  computations  onto  the  network.  In  this  scenario, 
the  idle  processors  of  any  desktop  computers  attached  to  the  network  can  be  utilized  to 
calculate  all  the  decision  parameters  essentially  in  parallel.  Depending  on  the  amount  of 
network  traffic  present,  the  entire  decision  parameter  matrix  could  be  hypothetically 
calculated  in  the  same  amount  of  time  it  now  takes  to  complete  just  one  complex  decision 
parameter  query. 

3.  Future  Scenario:  The  Final  Episode. 

Users  want  to  shape  the  technology  that  is  implemented  in  their 
organization.  They  want  to  control  its  use  and  determine  the  effect  it  will 
have  on  their  own  work.  They  are  rapidly  understanding  that  their 
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effective  use  of  technology  coupled  with  a  change  in  how  they  do  business 
will  determine  their  personal  and  organizational  success.  (Tapscott,  1993, 
p.  14) 

As  component-based  computing  becomes  more  and  more  the  norm  for  application 
development  within  civilian  and  military  organizations,  developing  future  IT  decision 
support  systems  may  become  a  far  easier  and  user-friendlier  process.  Just  ask  Colonel 
McMurdo  about  his  ARGIS  21  system: 

1721  HRS:  “Hey  Jack!  That  ARGIS  21  product  is  your  responsibility,  right?”  It 
was  Brigadier  General  Mark  Rutherford,  Col.  McMurdo ’s  immediate  boss,  on  the  phone. 
“Yes  Sir,”  the  Colonel  replied. 

“Well  the  Old  Man  just  got  a  call  about  the  BRAC  situation  on  CNN.  After  that 
’stick-save’  at  the  hearing  today,  you’re  stock  is  up  20  prestige  points.  As  a  matter  of 
fact,  you  have  a  meeting  with  the  Chairman  and  the  other  Four  Stars  in  the  Tank  first 
thing  tomorrow  morning  Seems  they  have  big  plans  for  ARGIS  21  concerning  better 
force  dispersion,  limited  over-the-horizon  target  selection,  and  real-time  Joint  logistics 
shipping  status.  You’d  better  bring  that  laptop  of  yours.” 

“I’m  on  it.  Sir,”  McMurdo  responded,  “and  while  I’m  at  it.  I’d  better  give  those 
people  back  at  NFS  a  call.  Looks  like  we’re  going  to  be  quite  busy.” 
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APPENDIX  A.  ARIES  SOURCE  DATA  FILE  META-DATA. 


This  appendix  contains  the  meta-data  that  was  documented  for  the  ARIES  SDSS 
prototype  data  source  files.  “ACROPOLIS”  as  used  in  this  appendix  refers  to  the  file 
name  of  the  ARIES  data  migration  warehouse  (DMW). 


Index 

1.  AMSA . 91 

2.  COMMAND  PLAN . 93 

3.  COMPLEX . ...95 

4.  ECS . . . 97 

5.  FINANCE . 99 

6.  EPS . 101 

7.  FYxxLOSS . 103 

8.  G17 . 105 

9.  G18CWE . 107 

10.  G19TRUE . 109 

11.  GEOREF . Ill 

12.  INTEREST . 113 

13.  IRR . 115 

14.  NGNON_CL . 117 

15.  QMA . . . 119 

16.  RPINFODT . 121 

17.  RZA . 123 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  AMSA  Location:  ../Aries/MapBasic/USARCData 

File  Type:  FoxPro  2.6 _  Size(MB):  .026 _  No.  Records:  190 _ 

Associated  ARIES  Tables:  Not  in  ACROPOLIS,  Geocoded  for  use  in  Maplnfo _ 

File  Description: 

AMSA  File  contains  information  about  the  location  of  each  AMSA  station.  It  is  used  in  determining  the 
value  for  the  distance  to  the  nearest  AMSA. 


Required  Data  Elements 


Extract  Queries: 


NONE 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  COMMAND  PLAN _  Location:  ACROPOLIS _ 

File  Type:  FoxPro  2.6 _  Size(MB):  3.29  No.  Records:  9,897 

Associated  ARIES  Tables:  CMDPLAN 

File  Description: 

Command  Plan  is  the  file  that  contains  information  about  each  unit  in  the  Army  Reserve.  It  is  used  to 
cross  reference  FAC  ID's  with  UIC's.  It  is  also  used  to  screen  for  Valid  UlC's  with  in  the  next  13  months. 


Required  Data  Elements 

__  I  ^  ^  Data  I  I 

Name  _ Description _ Type  Format  Field 

UIC  Unit  Identification  Code  Char  yes 

FACID  Facility  Identification  Code  Char  no 

EDATE  Effective  Date  of  Transaction  Char  no 


Extract  Queries: 

CMDPLAN 

SELECT  DISTINCT  UIC,  FACID  AS  FAC_ID, 
EDATE 

FROM  COMMANDPLAN 
WHERE  (FACID  o  "N/A")  AND  (FACID  o 
"TBD")  AND  (FACID  o  "")  AND 
(LEN(FACID)  >  2)  AND 
((LEFT(EDATE,4)  =  '1998'  AND 
MID(EDATE,5,2)  <=  '02')  OR 
(LEFT(EDATE,4)  <=  '1997')) 
ORDER  BY  UIC,  EDATE  DESC 
INTO  CMDPLAN 
INDEX  ON  UIC  as  UIC 
Note:  Application  automatically  adjusts  the 
dates  to  obtain  a  13  month  window. 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  COMPLEX _  Location:  ACROPOLIS _ 

File  Type:  FoxPro  2.6 _  Size(MB):  2.1 _  No.  Records:  1,557 

Associated  ARIES  Tables:  COMPLEX 


File  Description: 

The  Complex  File  is  used  to  determine  if  the  facility  is  owned  by  or  leased  to  the  government  and  the 
number  of  weekends  each  facility  is  used  during  a  month. 


Required  Data  Elements 


Name 

Description 

Data 

Type 

Format 

Key..: 
Field  1 

FACJD 

Facility  Identification  Code 

Char 

yes 

GOVT_OWN 

Facility  ownership  status 

Char 

Y/N 

no 

RS_WKND_PM 

Reserve  Station  weekend  usage  per  mo. 

Number 

0-4 

no 

Extract  Queries: 

COMPLEX_ 

SELECT  FACJD,  GOVT_OWN  AS 

FAC_OWNED,  RS_WKND_PM  AS 
FAC_WKND_USED 
FROM  COMPLEX 
WHERE  LEN(FAC_ID)  =  5 
INTO  COMPLEX_ 

INDEX  ON  FACJD  as  FACID,  Primary,  Unique 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  ECS  Location:  , ,  AMapBasicMJSARCDataV 

File  Type:  FoxPro  2.6 _  Size(IVIB):  .004  No.  Records:  30 _ 

Associated  ARIES  Tables:  Not  in  ACROPOLIS,  Geocoded  for  use  in  Mapinfo _ _ 


File  Description: 

ECS  File  contains  information  about  the  location  of  each  Equipment  Center.  It  is  used  in  determining  the 
distance  to  the  nearest  ECS. 


faczip 


abb_type 


Required  Data  Elements 

Description 

Data 

Type 

Facility  Identification  Code 

Char 

Facility  Title 

Char 

Street  Address  of  Facility 

Char 

City  Facility  is  located  in 

Char 

State  Facility  is  located  in 

Char 

Zip  Code  of  the  Facility 

Char 

,  V.:. :  Key  ^ 

Format  Field : 


Extract  Queries: 
NONE 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  FINANCE  Location:  ACROPOLIS 

File  Type:  FoxPro  2.6 _  Size(MB):  83.4 _  No.  Records:  311,793 

Associated  ARIES  Tables:  FINANCE_,  FINANCE_QTR _ 

File  Description; 

Finance  is  the  file  that  contains  pay  information  for  the  previous  eight  quarters  about  every  Reservist.  It  is 
used  to  obtain  information  about  Drill  Attendance  for  a  given  Facility. 


Required  Data  Elements 

Data 

Type  Format 

Char _ 

Number 

Number _ 

Number 
Number 
Number 


Number 

Number 


Extract  Queries: 

FINANCE_ 

FINANCE  QTR 

SELECT  "W"  &  LEFT(CURR  U1C,5)  AS  UIC, 

SELECT  "W"  &  LEFT(CURR_UIC,5)  AS  UIC, 

COUNT(CURR  UIC)  AS 

UTAIQCFY,  UTA2QCFY,  UTA3QCFY, 

UIC_TOTAL 

UTA4QCFY,  UTAIQIPF,  UTA2Q1PF, 

FROM  FINANCE 

UTA3Q1PF,  UTA4Q1PF 

WHERE  CURR  UIC  o  "" 

FROM  FINANCE 

ORDER  BY  CURR_UIC 

WHERE  CURR  UIC  o  ""  AND  NPS  IND  =  NULL 

GROUP  BY  CURR  UIC 

AND  PAY  STAT  =  'A’ 

INTO  FINANCE 

ORDER  BY  CURR  UIC 

INDEX  ON  UIC  as  UIC 

INTO  FINANCE_QTR 

INDEX  ON  UIC  as  UIC 

Name 

Description 

CURR_UIC 

Current  Unit  Identification  Code 

UTAIQCFY 

Unit  Training  Attendance  for  Qtr  this  FY 

UTA2QCFY 

Unit  Training  Attendance  for  2"''  Qtr  this  FY 

UTA3QCFY 

Unit  Training  Attendance  for  3'^''  Qtr  this  FY 

UTA4QCFY 

Unit  Training  Attendance  for  4“'  Qtr  this  FY 

UTAIQIPF 

Unit  Training  Attendance  for  Qtr  last  FY 

UTA2QIPF 

Unit  Training  Attendance  for  2""^  Qtr  last  FY 

UTA3Q1PF 

Unit  Training  Attendance  for  3'"*  Qtr  last  FY 

UTA4Q1PF  Unit  Training  Attendance  for  4‘^  Qtr  last  FY 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  FPS _  Location:  ACROPOLIS _ 

File  Type:  FoxPro  2.6 _ _  Size(MB):  .088  No.  Records:  1,561 

Associated  ARIES  Tables:  FPS_  _ _ _ 

File  Description: 

FPS  is  used  to  obtain  information  about  the  Cost  to  operate  each  facility  as  well  as  the  Condition  of  each 
Facility.  Used  to  return  a  value  for  the  Cost  per  Square  Foot  and  the  Facility  Condition. 


Required  Data  Elements 


■V  Name 

Description 

Data 

Type 

Format 

Key 

Field 

FAC  ID 

Facility  Identification  Code 

Char 

No 

Condition  of  the  Facility 

Char 

No 

Cost  per  Square  Foot  to  Operate  Facility 

Mumber 

No 

• 

Extract  Queries: 

FPS_ 

SELECT  FACJD,  FAC_COND,  COST_PR_SF 
FROM  FPS 
WHERE  FACJD  o  "" 

ORDER  BY  FACJD 
INTO  FPS_ 

INDEX  ON  FACJD  as  FACID,  Primary,  Unique 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  FYxxLOSS _  Location:  ACROPOLIS _ 

File  Type:  FoxPro  2.6  Size(MB):  85.4  No.  Records:  260,000 

Associated  ARIES  Tables:  FYxxLOSS,  FYxxXFER _ 

File  Description: 

FYxxLOSS  file  contains  information  about  the  personnel  losses  incurred  by  each  unit  during  a  fiscal  year. 
It  is  used  to  determine  the  Average  Loss  and  Transfer  Rate  of  a  Unit. 


Required  Data  Elements 

Data  Key 

Name  Description _  type  Format  Field 

UIC  Unit  Identification  Code _ Char _ No 

TRMN  Transfer  Reason  Code  Char  No 


Extract  Queries: 

FYxxLOSS 

FYxxXFER 

SELECT  UICl  AS  UIC,  COUNT(UICl)  AS 

SELECT  UICl  AS  UIC,  COUNT(UICI)  AS 

UIC  TOTAL 

UIC  TOTAL 

FROM  FY  LOSS 

FROM  FY_LOSS 

WHERE  TRMN  =  'LOSS' 

WHERE  TRMN  =  TRFD’ 

ORDER  BY  UICl 

ORDER  BY  UICl 

GROUP  BY  UICl 

GROUP  BY  UICl 

INTO  FYxxLOSS 

INTO  FYxxXFER 

INDEX  ON  UIC  as  UIC,  Primary,  Unique 

INDEX  ON  UIC  as  UIC,  Primary,  Unique 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  G17 _ 

File  Type:  FoxPro  2.6 _ 

Associated  ARIES  Tables:  G17Natl 


Location:  ACROPOLIS 


Size(MB):  3.11 


No.  Records:  5,869 


File  Description: 

G17  file  contains  facility  Unitname,  street  address  data  and  Zip  Code.  It  is  used  as  the  primary  cross 
reference  with  Command  Plan  to  display  facility  information  and  validate  user  input. 


Required  Data  Elements 


■ ''Name 

De$cription 

Data 

Type 

UIC 

Unit  Identification  Code 

Char 

UNITNAME 

Name  of  the  Unit 

Char 

TCCCITY 

City  Unit  is  located  in 

Char 

TCCSTATE 

State  Unit  is  located  in 

Char 

TCCZIP 

Zip  code  of  the  Unit 

Char 

TIER 

Code  used  to  determine  if  Unit  is  closing 

Char 

RECSTAT 

Recruiting  Station  Code 

Number 

TYPEORG 

Type  of  organization 

Number 

Key 

Format  Field 


Extract  Queries: 

GlTNatl 

SELECT  UIC,  UNITNAME,  TCCCITY  AS 
CITY,  TCCSTAT  AS  STATE, 
LEFT(TCCZIP,5)  AS  ZIP,  TIER 
FROM  G17 

WHERE  (RECSTAT  o  "  1 ")  AND  (TYPEORG 
o  "2")  AND  UIC  o  "" 

ORDER  BY  UIC 
INTO  G17Natl 

INDEX  ON  UIC  as  UIC,  Primary,  Unique 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  G18CWE  Location:  ACROPOLIS;..\MapBasic\UsarcDat 

a _ 

File  Type:  FoxPro  2.6 _  Size(MB):  145.9  No.  Records:  208,416 

Associated  ARIES  Tables:  G18Natl,  G18Natl_UIC;  also  Geocoded  for  use  in  Mapinfo _ 

File  Description: 

G18  File  contains  information  about  personnel  in  the  US  Army  Reserves.  It  is  used  in  determining  the 
Total  Number  Assigned  used  in  calculating  the  Loss/Transfer  Rates,  Total  Available  Closing  and  the 
Reassignments  values.  Also  used  to  obtain  a  list  of  the  Zip  Code’s  and  MOSs  of  every  Reservists  with  their 
associated  UIC.. 

Required  Data  Elements 


Extract  Queries: 

G18Natl 

GI8Natl  UIC 

SELECT  UIC,  LEFT(ZIP,5)  AS  ZIPCODE, 

SELECT  UIC,  COUNT(UIC)  AS  UIC_TOTAL 

LEFT(PRI,3)  AS  MOS 

FROM  GI8Natl 

FROM  G18 

ORDER  BY  UIC 

WHERE  PRI  o  ""  AND  UIC  o  "" 

GROUP  BY  UIC 

ORDER  BY  UIC 

INTO  G18Natl_UIC 

INTO  G18Natl 

INDEX  ON  UIC  as  UIC 

INDEX  ON  UIC  as  UIC,  Primary,  Unique 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  G19TRUE _  Location:  ACROPOLIS _ _ 

File  Type:  FoxPro  2.6  Size(MB):  14.4  No.  Records:  233,211 

Associated  ARIES  Tables:  G19Natl _ 

File  Description: 

G19  File  contains  information  about  the  required  manning  levels  of  each  Unit.  It  is  used  in  determining 
Average  Area  Manning  for  a  Facility. 


Required  Data  Elements 


•  ■  'Data  :: 

Name  Description  Type  Format  F|eld 


Extract  Queries: 


G19Natl 

SELECT  OWN_UIC  AS  UIC, 

COUNT(OWN_UIC)  AS 
UIC_TOTAL 
FROM  G19 
WHERE  OWN_UIC  o "" 
ORDER  BY  OWN_UIC 
GROUP  BY  OWN_UIC 
INTO  G19Natl 
INDEX  ON  UIC  as  UIC 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  GEOREF _  Location;  ACROPOLlS;..\MapBasic\UsarcData 

File  Type:  FoxPro  2.6 _  Size(MB):  .21 _  No.  Records:  1,553 _ 

Associated  ARIES  Tables:  VALID_UNIT;  also  Geocoded  for  use  in  Mapinfo _ 


File  Description: 

Georef  File  contains  specific  information  about  each  Unit,  It  is  used  to  verify  and  cross  reference  FACID's 
•  and  UIC  as  well  as  Facility  and  Unit  specific  information. 


Required  Data  Elements 


Name  ■ 

Description 

Format 

/.Key  > 
Field  i 

FACJD 

Facility  Identification  Code 

Char 

No 

Name  of  the  Facility 

Char 

No 

City  the  Facility  is  located  in 

No 

State  the  Facility  is  located  in 

No 

Zip  Code  of  the  Facility 

Char 

No 

Latitude 

Position  of  Facility  by  degree  of  latitude 

Number 

No 

Longitude 

Position  of  Facility  by  degree  of  longitude 

Number 

No 

Extract  Queries: 

VALID_UNIT 

SELECT  FACJD,  FAC_TITLE  AS 

UNITNAME,  FAC_CITY  AS  CITY, 
FAC_STATE  AS  STATE, 
LEFT(FAC_ZIP,5)  AS  ZIP 
FROM  GEOREF 
WHERE  FACJD  o 
ORDER  BY  FACJD 
INTO  VALID_UNIT 
INDEX  ON  FAC  IDasFACID 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  INTEREST _  Location:  ACROPOLIS _ 

File  Type:  FoxPro  2.6 _  Size(MB):  4.2 _  No.  Records:  3,985 

Associated  ARIES  Tables:  INTEREST_ _ 

File  Description; 

Interest  File  contains  information  about  facilities  and  the  date  they  were  acquired.  It  is  used  to  calculate 
the  Facility  Age  for  each  facility.. 


Required  Data  Elements 


Name 

Description 

Data 

Format 

Key 

Field 

Facility  Identification  Code 

Char 

No 

1  DATE  ACO 

Date  Facility  Acquired 

Date 

No 

Extract  Queries: 


INTEREST_ 

SELECT  FACJDSTR  AS  FACJD,  DATE_ACQ 
FROM  INTEREST 

WHERE  FACJDSTR  o  ””  AND  ABB_TYPE  = 
"USARC(MB)"  AND  NOT 
ISNULL(DATE_ACQ) 

ORDER  BY  FACJDSTR 
INTO  INTEREST_ 

INDEX  ON  FACJD  as  FACID,  Primary,  Unique 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  IRR _  Location:  . .  .\MapBasic\UsarcData _ 

File  Type:  FoxPro  2,6  Size(MB):  7.5  No.  Records:  140,077 

Associated  ARIES  Tables:  Not  in  ACROPOLIS,  Geocoded  for  use  in  Mapinfo _ 

File  Description: 

IRR  File  contains  information  about  the  individuals  listed  in  the  Individual  Ready  Reserve.  It  is  used  to 
determine  the  value  for  IRR  Available  and  Available  MOS  IRR. 


Required  Data  Elements 


Extract  Queries: 


NONE 


THIS  PAGE  LEFT  INTENTIONALLY  BLANK 


116 


ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  NGNON_CL  Location:  « .  AMapBasicMJsarcData 

File  Type:  FoxPro  2.6  Size(MB):  .64  No.  Records:  3,673 

Associated  ARIES  Tables:  Not  in  ACROPOLIS,  Geocoded  for  use  in  Mapinfo _ 

File  Description: 

NGNON_CL  File  contains  information  about  the  non-closing  National  Guard  Units.  It  is  used  in 
determining  the  value  for  Competition. 


Required  Data  Elements 


Name  Description _  Type  Format  Field 

UPC . . . Char _ Yes 

ZIP  Zip  Code  for  National  Guard  Individual  Char  Yes 


Extract  Queries: 
NONE 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  QMA  Location:  . .  .\MapBasic\UsarcData 

File  Type:  FoxPro  2.6 _  Size(MB):  2.8 _  No.  Records:  34,265 

Associated  ARIES  Tables:  Not  in  ACROPOLIS,  Geocoded  for  use  in  Mapinfo _ 

File  Description: 

QMA  File  contains  Census  information.  It  is  used  in  determining  the  value  for  Recruit  Market  for  each 
Facility. 


Required  Data  Elements 


V.  .  ■  Dm  ■  |Key 

Name  ■■■  ^ Description  ■ ''-•\..Type  Format  Field 

ZIP  Zip  Code _ Char _ No 

MWCAT12  White  Male  Mental  Categories  1  &2  Number _ No 

MWCAT3A  White  Male  Mental  Category  3A  Number _ No 

MBCAT12 _ Black  Male  Mental  Categories  1  &2 _ Number _ No 

MBCAT3A  Black  Male  Mental  Category  3A  Number _ No 

MHCAT12  Hispanic  Male  Mental  Categories  1  &2  Number _ No 

MHCAT3A  Hispanic  Male  Mental  Category  3A  Number  No 


Extract  Queries: 


NONE 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name;  RPINFODT 

File  Type:  FoxPro  2.6 _ 

Associated  ARIES  Tables:  FPINFODT 


Location:  ACROPOLIS _ 

Size(MB):  14.3  No.  Records:  47,159 


File  Description: 

RPINFODT  is  a  file  that  contains  information  about  the  backlogged  maintenance  costs  of  each  Facility.  It 
is  used  to  determine  the  amount  of  backlogged  maintenance  is  required  at  the  given  Facility. 


Required  Data  Elements 


Name 

Description 

Data 
Type  , 

Format 

;‘'Key'  ; 

Field  ^ 

FACJD 

Facility  Identification 

Char 

No 

Total  amount  of  outstanding  Maint.  Actions 

Number 

No 

Extract  Queries: 

RPINFODT_ 

SELECT  FACJD,  SUM(CWE_TOTAL)  AS 
MAINT_COST 
FROM  RPINFODT 
WHERE  FACJD  o  "" 

ORDER  BY  FACJD 
GROUP BY  FACJD 
INTO  RPINFODT_ 

INDEX  ON  FACJD  as  FACID,  Primary,  Unique 
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ARIES  Data  File  Documentation  Form 


ARIES  File  Name:  RZA  Location:  . .  .\MapBasic\UsarcData 

File  Type:  FoxPro  2.6 _  Size(MB):  .16 _  No.  Records:  1,793 

Associated  ARIES  Tables:  Not  in  ACROPOLIS,  Geocoded  for  use  in  Mapinfo 

File  Description: 

RZA  File  contains  information  about  the  location  of  Recruit  Stations.  It  is  used  to  determine  the  distance 
>  to  the  nearest  Recruit  Station. 


Required  Data  Elements 

■■:;Data  , .  Ke^' ' 

Name  Description  Type  Format  Field 

rsid _ Recruit  Station  Identification  Code _  Char  No 

name  Recruit  Station  Title  Char  No 

zip _ Zip  Code  of  the  Recruit  Station _  Char  No 

latitude _  Position  of  Recruit  Station  by  latitude  Number  No 

longitude  Position  of  Recruit  Station  by  longitude  Number  No 


Extract  Queries: 
NONE 
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APPENDIX  B.  ARIES  BUSINESS  RULES  AND  PROCESSES. 


This  appendix  contains  detailed  information  about  the  calculation  of  each  ARU-Decision 
Model  parameter  that  was  automated  in  the  ARIES  SDSS  prototype  application.  The 
information  includes  a  description  of  each  decision  parameter,  the  business  rule  used  to  calculate 
the  associated  value,  base  units,  source  files,  associated  data  migration  warehouse 
(ACROPOLIS)  tables,  query  or  queries  involved  in  the  calculation,  a  description  of  the  yield 
curve,  and  a  graph  of  the  yield  curves.  “ACROPOLIS”  is  the  file  name  for  the  ARIES  data 
resource  file. 

The  term  “in  the  area”  in  this  Appendix  is  defined  as  being  with  in  a  50-mile  radius  of  the 
moving  xmit  or  proposed  facility. 


Index 

Decision  Parameter  1.  Facility  Backlogged  Maintenance . 127 

Decision  Parameter  2.  Facility  Operating  Costs . 129 

Decision  Parameter  3 .  Facility  Age . 131 

Decision  Parameter  4.  Facility  Condition . 133 

Decision  Parameter  5.  Facility  Ownership . 135 

Decision  Parameter  6.  Competition . 137 

Decision  Parameter  7.  Average  Area  Drill  Attendance . 139 

Decision  Parameter  8.  Area  Loss  Rate . 141 

Decision  Parameter  9.  Area  Transfer  Rate . ; . 143 

Decision  Parameter  10.  Area  Average  Manning . 145 

Decision  Parameter  1 1 .  Distance  to  Nearest  Recruit  Station . 147 

Decision  Parameter  12.  Available  Transfers  from  Closing  Units . . . 149 

Decision  Parameter  1 3 .  IRR  Available . 151 

Decision  Parameter  14.  Recruit  Market . 153 

Decision  Parameter  15.  Reassignments . 155 

Decision  Parameter  16.  Distance  to  Area  Maintenance  Support  Activity . 157 

Decision  Parameter  17.  Distance  to  Nearest  Equipment  Concentration  Site . 159 

Decision  Parameter  18.  Facility  Weekends  Used . 161 

Decision  Parameter  19.  Available  MOS  from  Closing  Units . 163 

Decision  Parameter  20.  Available  MOS  IRR . 167 
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Decision  Parameter  1.  Facility  Backlogged  Maintenance 

Definition:  Facility  Backlogged  Maintenance  provides  the  total  dollar  value  of  backlogged 

maintenance.  This  provides  an  indication  of  the  initial  investment  required  to 
correct  the  significant  maintenance  problems  with  a  proposed  facility. 

Calculation:  The  Backlogged  Maintenance  value  is  based  upon  the  sum  values  for  maintenance 
actions  documented  for  each  facility  in  the  “CWE_TOTAL”  field  of  the 
RPINFODT  file.  The  summation  is  done  during  the  data  extraction  phase. 

Maint_Cost[Sum  of  outstanding  maintenance  actions  for  a  facility] 

Units:  Dollars 


Source  File:  RPINFODT 


ACROPOLIS  Table(s):  RPINFODT_ 

Query:  MaintCost 

SELECT  MAINT_COST 
FROM  RPINFODT_ 

WHERE  RPINFODT_.FACID  =  ProposedFacility.FACJD 

Yield  Curve:  A  linear  relationship  is  assumed  between  the  backlogged  maintenance  costs  and 
utility.  Every  dollar  required  or  saved  in  this  category  is  expected  to  have  equal 
utility  to  a  relocating  unit. 


Max  Utility:  0  Min  Utility:  >  1,000,000 
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DECISION  PARAMETER  2.  Facility  Operating  Costs 


Definition;  Facility  Operating  Costs  provide  an  indication  of  the  financial  resources  that  are 
required  to  maintain  the  facility  in  a  serviceable  condition.  This  includes  both 
utilities  and  minor  maintenance  costs. 


Calculation:  Operating  Costs  are  extracted  from  the  “COST_PR_SF”  field  of  the  FPS  file. 

COST_PR_SF[Retrieve  the  Cost  per  Square  Foot  for  a  facility] 

Units;  Dollars  per  square  foot  per  month 

Source  File:  FPS 


ACROPOLIS  Table(s):  FPS_ 

Query;  COST_PR_SF 

SELECT  COST_PR_SF 
FROM  FPS_ 

WHERE  FPS_.FACID  =  ProposedFacility.FACJD 

Yield  Curve:  A  linear  relationship  is  assumed  between  the  operating  costs  and  utility.  Every 
dollar  required  or  saved  in  this  category  is  expected  to  have  equal  utility  to  a 
relocating  unit. 
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Decision  Parameter  3.  Facility  Age 


Definition:  This  Decision  Parameter  indicates  the  age  of  the  primary  structure  on  the 

proposed  relocation  site.  It  is  intended  to  reflect  an  assumed  long  term  structural 
degradation  with  time. 

Calculation;  Facility  age  is  calculated  based  upon  the  acquisition  date  found  in  the  INTEREST 
file.  The  acquisition  date  is  compared  to  the  current  date  and  the  difference  is 
determined  in  months. 


DATE  ACQ  [Current  Year  -  Date  Acquired] 


Units:  Months 

Source  File:  INTEREST 


ACROPOLIS  Table(s):  INTEREST_ 

Query:  DATE_ACQ 

SELECT  DATE_ACQ 
FROM  INTEREST_ 

WHERE  INTEREST_.FACID  =  ProposedFacility.FACJD 
Yield  Curve:  A  linear  relationship  is  used  between  facility  age  and  utility. 


Max  Utility:  0 


Min  Utility:  >1,200 
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Decision  Parameter  4.  Facility  Condition 

Definition:  Facility  Condition  is  based  upon  a  visual  inspection  of  the  stracture  and  provides 

an  indication  of  the  serviceability  of  the  primary  structures. 

Calculation:  This  Decision  Parameter  is  based  upon  the  ISR  part  1  rating  entered  in  the 
“FAC_COND”  field  of  the  FPS  file. 

FAC_COND  [Retrieve  Facility  Condition] 

Units:  No  Units(Green,  Amber,  Red) 

Source  File:  FPS 

ACROPOLIS  Tablets):  FPS_ 

Query:  FAC_COND 

SELECT  FAC_COND 
FROM  FPS_ 

WHERE  FPS_.FACID  =  ProposedFacility.FACJD 

Yield  Curve:  The  utility  of  these  three  categories  varies  in  discrete  steps.  A  facility  that  is 
categorized  as  “green”  is  judged  to  be  approximately  twice  a  desirable  as  one  that 
is  assigned  an  “amber”  rating. 


RED  AMBER  GREEN 


Max  Utility:  GREEN  Min  Utility:  RED 
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Decision  Parameter  5.  Facility  Ownership 

Definition;  This  Decision  Parameter  indicates  whether  the  facilities  at  a  proposed  relocation 
site  are  leased  or  owned. 

Calculation:  Facility  Ownership  is  based  upon  the  entry  in  the  “GOVT_OWN”  field  of  the 
COMPLEX  file. 

GO VT  OWN  [Retrieve  Ownership  Status] 

Units:  No  Units(Yes/No) 

Source  Data:  COMPLEX 

ACROPOLIS  Table(s):  COMPLEX_ 

Query:  GOVT_OWN 

SELECT  GOVT_OWN 
FROM  COMPLEX_ 

WHERE  COMPLEX_.FACID  =  ProposedFacility.FACJD 

Yield  Curve:  Facilities  that  are  owned  by  the  government  are  preferred  as  relocation  sites  over 
those  facilities  that  are  leased.  The  owned  sites  are  assigned  the  maximum  utility 
value  of  1 .0,  while  leased  sites  are  given  a  0  utility  score. 


Max  Utility;  Yes  Min  Utility;  No 
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Decision  Parameter  6.  Competition 

Definition;  This  Decision  Parameter  provides  an  indication  of  the  level  of  competition  for 
potential  reservists.  It  considers  only  Army  Reserve  and  Army  National  Guard 
units  in  the  area  of  the  relocation  site. 

Calculation;  Competition  is  determined  by  the  number  of  positions  that  must  be  filled  by  all 
other  Army  Reserve  and  Army  National  Guard  (ARNG)  units  in  the  area  of  the 
proposed  relocation  site.  For  Army  Reserve  units,  the  number  of  required 
positions  is  determined  by  coimting  the  number  of  records  in  the  G19TRUE  file 
associated  with  each  UIC  in  the  area.  For  ARNG  units,  the  value  is  found  in  the 
“AUTH”  field  of  the  NGNON_CL  file. 

NO_AUTH_NG[Number  Authorized  National  Guard]  + 

NO  REQD [Number  Area  Reservists  Required] 

Units;  Number  of  competing  positions 

Source  File;  COMMAND  PLAN,  G1 7,  G1 9TRUE,  GEOREF,  NGNON_CL 

ACROPOLIS  Table(s);  CMDPLAN,  GlTNatl,  G19Natl,  VALID_UIC 

Query;  Area-FACID  List(MapInfo) 

SELECT  FACJD  iNTO  TempFACID 

FROM  GEOREF 

WHERE  Object  Within  ObJAreaBuffer 

ORDER  BY  FACJD 

(Note;  ObJAreaBuffer  is  equal  to  300  miles) 

VALID_UIC 

SELECT  UIC,  FACJD,  UnitName,  City,  State,  Zip 
FROM  GlTNatl 

WHERE  G17Natl.UIC  =  ANY  (SELECT  CMDPLAN.UIC 

FROM  CMDPLAN) 


Area-UIC  List 

SELECT  DISTINCT  UIC  INTO  AREA_UIC 
FROM  VALID_UIC 

WHERE  VALID_UIC.FACJD  =  ANY  (SELECT  AREA_FACID.FACJD 

FROM  AREA_FACID) 


NO_AUTH_NG(MapInfo) 
SELECT  *  INTO  TempNGUnits 
FROM  NON_CLOS 
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WHERE  Obj  Within  ObjAreaBuffer 

SELECT  SUM(AUTH)  “No_AUTH_NG”  INTO  Strength 
FROM  TempNGUnits 

NO_REQD 

SELECT  SUM(UIC_TOTAL)  AS  TOTAL_REQD 
FROM  G19Natl 

WHERE  G 1 9Natl.UIC  =  ANY  (SELECT  AREA_UIC.UIC 

FROM  AREA_UIC) 

Yield  Curve:  A  linear  relationship  exists  between  the  number  of  competing  positions  from  other 
units  and  the  utility  of  a  relocation  site.  The  level  of  no  site  utility  in  this 
Decision  Parameter  begins  at  10,000  positions  which  is  above  the  maximum  value 
expected. 


Utility 


Max  Utility:  0 


Min  Utility:  >10,000 
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Decision  Parameter  7.  Average  Area  Drill  Attendance 

Definition:  This  Decision  Parameter  indicates  the  fraction  of  reservists  with  satisfactory  drill 

attendance  for  all  existing  units  in  the  area  of  the  proposed  relocation  site.  Areas 
with  a  high  fraction  of  satisfactory  drill  attendance  are  preferred  relocation  sites 
because  units  relocated  to  that  area  are  assumed  to  perform  similarly  in  drill 
attendance. 

Calculation:  This  Decision  Parameter  considers  the  last  four  quarters  of  data  contained  in  the 
FINANCE  file.  After  initial  screening,  the  number  of  reservist  with  21  or  more 
drill  periods  for  the  year  is  divided  by  the  total  number  of  people  who  meet  the 
screening. 

DRILL_SAT  [Number  of  reservists  with  >  21  drill  periods  in  a  year] 
DR1LL_T0TAL  [Number  of  reservists  required  to  drill] 

Units:  Ratio 

Source  File:  COMMAND  PLAN,  FINANCE,  G1 7,  G1 9TRUE,  GEOREF 

ACROPOLIS  Table(s):  CMDPLAN,  FINANCE_,  FINANCE_QTR,  GlTNatl,  G19Natl, 

VALID_UIC 

Query:  Area-FACID  List(MapInfo) 

SELECT  FACJD  INTO  TempFACID 

FROM  GEOREF 

WHERE  Object  Within  ObjAreaBuffer 

ORDER  BY  FACJD 

(Note:  ObjAreaBuffer  is  equal  to  300  miles) 

VALID_UIC 

SELECT  UIC,  FACJD,  UnitName,  City,  State,  Zip 
FROM  GlTNatl 

WHERE  G1  TNatl.UIC  =  ANY  (SELECT  CMDPLAN.UIC 

FROM  CMDPLAN) 

Area-UIC  List 

SELECT  DISTINCT  UIC  INTO  AREA_UIC 
FROM  VALID_UIC 

WHERE  VALID_UIC.FACJD  =  ANY  (SELECT  AREA_FACID.FACJD 

FROMAREA_FACID) 
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FINANCE_CY 

SELECT  UIC,  COUNT(UIC)  AS  UIC_TOTAL  INTO  FINANCE_CY 
FROM  FINANCE_QTR 
WHERE  (Select  Case) 

Case  E'  Qtr  FY 

(UTAIQIPF  +  UTA2Q1PF  +  UTA3Q1PF  +  UTA4Q1PF)  >  20 
Case  2"' Qtr  FY 

(UTA2Q1PF  +  UTA3Q1PF  +  UTA4Q1PF  +  UTAIQCFY)  >  20 
Case  3'‘'QtrFY 

(UTA3Q1PF  +  UTA4Q1PF  +  UTAIQCFY  +  UTA2QCFY)  >20 
Case  4'"  Qtr  FY 

(UTA4Q1PF  +  UTAIQCFY  +  UTA2QCFY  +  UTA3QCFY)  >  20 
GROUP  BY  UIC 
ORDER  BY  UIC 

DRILL-SAT 

SELECT  SUM(UIC_TOTAL)  AS  TOTAL_SAT 
FROM  FINANCE_CY 

WHERE  FINANCE_CY.UIC  =  ANY  (SELECT  AREA_UIC.UIC 

FROM  AREA_UIC) 


DRILL-TOTAL 

SELECT  SUM(UIC_TOTAL)  AS  DRILL_TOTAL 
FROM  FINANCE_ 

WHERE  FINANCE_.UIC  =  ANY  (SELECT  AREA_UIC.UIC 

FROM  AREA_UIC.UIC) 

Yield  Curve:  The  utility  of  the  average  drill  attendance  rate  increases  linearly  between  the 
values  of  0  and  0.6.  Above  that  point,  increases  in  the  attendance  rate  result  in 
diminishing  returns.  Values  above  0.6  become  increasingly  uncommon. 


Utility 


Max  Utility:  1.0  Min  Utility:  0.0 
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Decision  Parameter  8.  Area  Loss  Rate 


Definition:  This  Decision  Parameter  indicates  the  fraction  of  reservists  who  left  the  reserves 

in  the  previous  fiscal  year,  for  all  existing  units  in  the  area  of  the  proposed 
relocation  site.  Areas  with  a  low  loss  rate  are  preferred  relocation  sites  because 
units  relocated  to  that  area  will  also  experience  low  loss  rates. 

Calculation:  The  number  of  losses  to  units  in  the  area  in  the  previous  fiscal  year  is  divided  by 
the  number  of  reservists  currently  assigned  to  these  units.  Losses  are  identified 
through  the  transfer  mnemonic  field  (TRMN=”LOSS”)  of  the  FyxxLOSS  file. 
The  number  of  assigned  reservists  is  determined  by  counting  all  of  the  personnel 
records  in  the  G18CWE  file  associated  with  each  UIC  in  the  area. 


NO_LOSS[Total  Number  of  Losses  in  the  last  year] 
NO_ASSN[Total  Number  Reservists  Assigned] 


Units:  Ratio 

Source  File:  COMMAND  PLAN,  FYxxLOSS,  G17,  G18CWE,  GEOREF 


ACROPOLIS  Table(s):  CMDPLAN,  FYxxLOSS,  G17Natl,  G18Natl_UIC,  VALID_UIC 


Query:  Area-FACID  List(MapInfo) 

SELECT  FACJD  INTO  TempFACID 

FROM  GEOREF 

WHERE  Object  Within  ObJAreaBuffer 

ORDER  BY  FACJD 

(Note:  ObJAreaBuffer  is  equal  to  300  miles) 

VALID_UIC 

SELECT  UIC,  FACJD,  UnitName,  City,  State,  Zip 
FROM  GlTNatl 

WHERE  G1  TNatl.UIC  =  ANY  (SELECT  CMDPLAN.UIC 

FROM  CMDPLAN) 


Area-UIC  List 

SELECT  DISTINCT  UIC  INTO  AREA_UIC 
FROM  VALID_UIC 

WHERE  VALID_UIC.FACJD  =  ANY  (SELECT  AREA_FACID.FACJD 

FROMAREA_FACID) 


NO_ASSN 

SELECT  SUM(UIC_TOTAL)  AS  TOTAL_ASSN 
FROM  G18Natl_UIC 
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WHERE  G1 8Natl_UIC.UIC  =  ANY  (SELECT  AREA_UIC.UIC 

FROM  AREA_UIC) 

NO_LOSS 

SELECT  SUM(UIC_TOTAL)  AS  TOTAL_LOSS 
FROM  FYxxLOSS 

WHERE  FYxxLOSS.UIC  =  ANY  (SELECT  AREA_UIC.UIC 

FROM  AREA_UIC) 

Yield  Curve;  This  function  includes  both  concave  and  convex  regions.  The  inflection  point 
occurs  at  a  loss  rate  of  .33  and  a  utility  of  0.5.  Based  on  experience,  a  loss  rate  of 
one  third  per  year  was  considered  to  be  typical.  Any  loss  rate  below  this  value 
has  relatively  high  utility,  whereas  loss  rates  above  the  inflection  point  quickly 
approach  a  utility  of  zero. 


Utility 


Max  utility:  0  Min  Utility:  1 
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Decision  Parameter  9.  Area  Transfer  Rate 


Definition:  This  Decision  Parameter  indicates  the  fraction  of  reservists  who  transferred  to 

different  units  in  the  previous  fiscal  year  for  all  existing  units  in  the  area  of  the 
proposed  relocation  site.  Areas  with  a  low  transfer  rate  are  preferred  relocation 
sites  because  units  relocated  to  that  area  will  also  experience  low  transfer  rates. 

Calculation:  The  number  of  transfers  in  the  previous  fiscal  year  is  divided  by  the  number  of 
reservists  currently  assigned  to  the  unit.  Transfers  are  identified  through  the 
transfer  mnemonic  field  (TRMN=”TRFD”)  of  the  FyxxLOSS  file.  The  number  of 
assigned  reservists  is  determined  by  counting  all  of  the  personnel  records  in  the 
G18CWE  file  associated  with  each  UIC. 


NO_XFER[Total  Number  of  Transfers  in  the  last  year] 
NO_ASSN[Total  Number  Reservists  Assigned] 


Units:  Ratio 

Source  File:  COMMAND  PLAN,  FYxxLOSS,  G17,  G18CWE,  GEOREF 


ACROPOLIS  Table(s):  CMDPLAN,  GlTNatl,  G1 8Natl_UIC,  FYxxXFER,  VALID_UIC 


Query:  Area-FACID  List(MapInfo) 

SELECT  FACJD  INTO  TempFACID 

FROM  GEOREF 

WHERE  Object  Within  ObjAreaBuffer 

ORDER  BY  FACJD 

(Note:  ObjAreaBuffer  is  equal  to  300  miles) 

VALID_UIC 

SELECT  UIC,  FACJD,  UnitName,  City,  State,  Zip 
FROM  GlTNatl 

WHERE  G1  TNatl.UIC  =  ANY  (SELECT  CMDPLAN.UIC 

FROM  CMDPLAN) 


Area-UIC  List 

SELECT  DISTINCT  UIC  INTO  AREA_UIC 
FROM  VALID_UIC 

WHERE  VALID_UIC.FACJD  =  ANY  (SELECT  AREA_FACID.FAC JD 

FROM  AREA_FACID) 
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NO_ASSN 

SELECT  SUM(UIC_TOTAL)  AS  TOTAL_ASSN 
FROM  G18Natl_UIC 

WHERE  G1 8Natl_UIC.UIC  =  ANY  (SELECT  AREA_UIC.UIC 

FROM  AREA_UIC) 


NO_XFER 

SELECT  SUM(UIC_TOTAL)  AS  TOTAL_XFER 
FROM  FYxxXFER 

WHERE  FYxxXFER.UIC  -  ANY  (SELECT  AREA_UIC.UIC 

FROM  AREA_UIC) 


Yield  Curve:  This  function  includes  both  concave  and  convex  regions.  The  inflection  point 
occurs  at  a  loss  rate  of  .33  and  a  utility  of  0.5.  Based  on  experience,  a  transfer  rate 
of  one  third  per  year  was  considered  to  be  typical.  Any  loss  rate  below  this  value 
has  relatively  high  utility  (close  to  1.0),  whereas  loss  rates  above  the  inflection 
point  quickly  approach  a  utility  of  zero. 


Max  Utility:  0  Min  Utility:  1 
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Decision  Parameter  10.  Area  Average  Manning 

Deflnition:  This  Decision  Parameter  indicates  the  ability  to  fill  the  required  positions.  An 

average  value  is  determined  for  all  existing  units  in  the  area  of  the  proposed 
relocation  site.  Areas  with  high  average  manning  levels  are  preferred  relocation 
sites  because  xmits  relocated  to  that  area  will  also  experience  high  manning  levels. 

Calculation:  The  nmnber  of  reservists  assigned  to  area  xmits  (based  upon  the  number  of 
persoimel  records  in  G18CWE  file  associated  with  each  UIC)  is  divided  by  the 
number  of  required  positions  (based  upon  the  number  of  positions  in  the 
G19TRUE  file  associated  with  each  UIC).  An  average  is  calculated  for  all  UIC’s 
in  the  area  of  the  proposed  site. 

NO_ASSN[Total  Number  Reservists  Assigned] 

NO_REQD  [Number  Area  Reservists  Required] 

Units:  Ratio 

Source  File:  COMMAND  PLAN,  G1 7,  G1 8CWE,  G1 9TRUE,  GEOREF 

ACROPOLIS  Table(s):  CMDPLAN,  GlTNatl,  G18Natl_UIC,  G19Natl,  VALID_UIC 

Query:  Area-FACID  List(MapInfo) 

SELECT  FACJD  INTO  TempFACID 

FROM  GEOREF 

WHERE  Object  Within  ObJAreaBuffer 

ORDER  BY  FACJD 

(Note:  ObJAreaBuffer  is  equal  to  300  miles) 

VALID_UIC 

SELECT  UIC,  FACJD,  UnitName,  City,  State,  Zip 
FROM  GlTNatl 

WHERE  G1  TNatl.UIC  =  ANY  (SELECT  CMDPLAN.UIC 

FROM  CMDPLAN) 

Area-UIC  List 

SELECT  DISTINCT  UIC  INTO  AREA  UIC 
FROM  VALID_UIC 

WHERE  VALID_UIC.FAC JD  =  ANY  (SELECT  AREA_FACID.FAC JD 

FROM  AREA_FACID) 
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NO_ASSN 

SELECT  SUM(UIC_TOTAL)  AS  TOTAL_ASSN 
FROM  G18Natl_UIC 

WHERE  G1 8Natl_UIC.UIC  =  ANY  (SELECT  AREA_UIC.UIC 

FROM  AREA_UIC) 


NO_REQD 

SELECT  SUM(UIC_TOTAL)  AS  TOTAL_REQD 
FROM  G19Natl 

WHERE  G1 9Natl.UIC  =  ANY  (SELECT  AREA_UIC.UIC 

FROM  AREA_UIC) 

Yield  Curve:  It  is  desirable  that  area  units  be  able  to  exceed  their  minimum  manning 
requirements.  All  manning  levels  above  125%  are  considered  to  have  maximum 
utility.  Manning  levels  below  this  value  drop  off  quickly  in  terms  of  utility. 


Max  Utility:  1.25  Min  Utility:  0 
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Decision  Parameter  11.  Distance  to  Nearest  Recruit  Station 

Definition:  Distance  to  the  nearest  Recruiting  Station  provides  one  indication  of  recruiter 

effectiveness. 

Calculation:  The  straight-line  distance  from  the  proposed  site  to  the  closest  recruiting  station  is 
calculated  using  a  geocoded  version  of  the  RZA  file. 

DIST_RZA[Determine  distance  to  nearest  Recruit  Station] 

Units:  Miles 

Source  Data:  RZA 

ACROPOLIS  Table(s):  NONE 

Query:  DIST_RZA(MapInfo) 

SELECT  * 

FROM  RZA 

WHERE  Obj  Withing  ObjDistanceBuffer  into  TempRZA 
(Note:  ObjDistanceBuffer  is  equal  to  300  miles) 

SELECT  Distance((CentroidX(Obj),  CentroidY(Obj),  FacIDLat,  FacIDLong,  “mi”) 
FROM  TempRZA 

ORDER  BY  Distance  INTO  TempRZA.Dist 

Yield  Curve:  The  effectiveness  of  a  recruiting  station  in  filling  positions  at  a  reserve  unit  is 
fairly  high  if  the  two  are  within  a  half  hour  drive  of  each  other.  It  is  assumed  that 
recruiters  are  most  effective  in  the  area  close  to  their  recruiting  station  and  that 
reserve  recruits  must  be  located  near  the  unit  with  which  they  will  serve.  A 
distance  of  30  miles  is  assigned  an  average  utility  of  0.5.  A  small  change  in 
distance  results  in  less  change  in  desirability  when  the  distance  is  very  small  or 
very  large  than  it  does  when  the  distance  is  around  30  miles. 


Max  Utility:  0 
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Decision  Parameter  12.  Available  Transfers  from  Closing  Units 

Definition:  This  value  indicates  the  total  number  of  personnel  assigned  to  closing  units  within 

50  miles  of  the  proposed  site. 

Calculation:  A  list  of  Unit  Identification  Codes  (UIC’s)  is  created  which  contains  only  those 
units  scheduled  to  close  within  1 8  months.  These  units  are  identified  by  an  entry 
of  5B  in  the  “Tier”  field  of  the  G17  file.  The  number  of  potential  transfers  fi'om 
closing  units  is  calculated  by  summing  the  number  of  records  in  the  G18CWE 
database  for  the  closing  units  which  are  located  in  the  area  of  the  proposed 
relocation  site. 

TOTAL_AVAIL[Total  Number  of  Available  Reservists  from  Area  Closing  Units] 

Units:  Ratio 

Source  File:  COMMAND  PLAN,  G17,  G1 8CWE,  GEOREF,  US_ZIPS(MapInfo) 

ACROPOLIS  Table(s):  CMDPLAN,  G1  TNatl,  VALID_UIC 

Query:  Area-FACID  List(MapInfo) 

SELECT  FACJD  INTO  TempFACID 

FROM  GEOREF 

WHERE  Obj  Within  objAreaBuffer 

ORDER  BY  FACJD 

(Note:  objAreaBuffer  is  equal  to  300  miles) 

VALID_UIC 

SELECT  UIC,  FACJD,  UnitName,  City,  State,  Zip 
FROM  G1  TNatl 

WHERE  G17Natl.UIC  =  ANY  (SELECT  CMDPLAN.UIC 

FROM  CMDPLAN) 


Area-UIC  List 

SELECT  DISTINCT  UIC  INTO  AREA_UIC 
FROM  VALID_UIC 

WHERE  VALID_UIC.FACJD  =  ANY  (SELECT  AREA_FACID.FACJD 

FROM  AREA_FACID) 


AREA_CLOS_UIC 
SELECT  UIC 
FROM  G1  TNatl 
WHERE  G17Natl.TIER  =  “5B” 

AND  GlTNatl.UIC  =  ANY  (SELECT  AREA_UIC.UIC 
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FROMAREA_UIC) 


AREA_ZIPCODE(MapInfo) 

SELECT  ZIP_CODE 
FROM  US_ZIPS 
WHERE  Obj  Within  objAreaBuffer 
ORDER  BY  ZIP_CODE 

Area_Gl  8_ZIP(MapInfo) 

SELECT  DISTINCT  UIC,  ZIPCODE,  COUNT(UIC)  AS  UIC_TOTAL 
FROM  G18CWE 
GROUP  BY  UIC,  ZIPCODE 
ORDER  BY  UIC,  ZIPCODE 

TOTAL_AVAIL 

SELECT  SUM(UIC_TOTAL)  AS  TOTAL_AVAIL 
FROM  Area_G18_ZIP 

WHERE  Area_Gl  8_ZIP.UIC  =  ANY  (SELECT  AREA_CLOS_UIC.UIC 

FROM  AREA_CLOS_UIC) 

AND  Area  Gl 8_ZIP.ZIPCODE  =  ANY  (SELECT  AREA_ZIPCODE.ZIP 

FROM  AREA_ZIPCODE) 

Yield  Curve:  The  shape  of  this  function  assumes  diminishing  returns  in  the  number  of  transfers 
available.  Experience  suggests  that  for  an  average  unit  of  100  people, 
approximately  half  have  prior  reserve  experience  and  that  approximately  half  of 
the  people  in  a  closing  unit  will  be  able  to  transfer  their  skills  directly  to  a  new 
imit.  The  value  of  the  first  100  reservists  increases  at  a  nearly  linear  rate  because 
they  provide  preferred  fills  for  approximately  50  of  the  positions  of  the  moving 
unit.  A  value  of  100  personnel  is  assigned  a  utility  of  0.9.  The  incremental  value 
added  by  each  additional  person  over  100  continues  to  drop  until  no  marginal  gain 
is  expected  over  500. 


Utility 


Max  Utility:  >  250 


Min  Utility:  0 


Definition: 

Calculation: 

Units: 

Source  File: 
Query: 


Yield  Curve: 


Decision  Parameter  13.  IRR  Available 

Individual  Ready  Reserve  (IRR)  Available  is  the  number  of  IRR  members  living 
in  the  area  of  the  proposed  relocation  site.  This  is  a  Decision  Parameter  of  the 
size  of  the  prior  service  market. 

A  geographical  query  returns  the  total  number  of  IRR  members  living  within  a 
specified  distance  of  the  proposed  relocation  site.  This  process  requires  a 
geocoded  version  of  the  IRR  file. 

TOTAL_IRR[Total  Number  of  Available  IRR  from  the  Area] 

People 

IRR 

ArealRR(MapInfo) 

SELECT  ZIPC  “ZIP”,  LEFT$(PMOS,  3)  “MOS” 

FROM  IRR 

WHERE  Obj  Within  objAreaBuffer 

AND  ZIPC  o  AND  PMOS  o 
ORDER  BY  ZIPC 

(Note:  objAreaBuffer  is  equal  to  300  miles) 

TOTALJRR 

SELECT  COUNT(*)  AS  TOTALJRR 
FROM  ArealRR 

For  a  typical  imit  of  100  people,  it  is  assumed  that  approximately  40  positions 
could  best  be  filled  by  IRR  members.  The  recruiting  fate  for  the  IRR  is 
approximately  1  percent,  so  an  area  that  offers  4,000  IRR  members  is  assigned  an 
average  utility  of  0.5.  Above  this  point,  there  are  diminishing  returns.  The 
market  begins  to  exceed  the  personnel  demand  of  a  moving  unit  and  limited 
recruiting  efforts  become  marginally  less  effective.  The  utility  of  smaller 
numbers  quickly  drops  off  because  of  the  importance  of  this  source  of  recruits. 


Max  Utility:  >  10,000  Min  Utility:  0 
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Decision  Parameter  14.  Recruit  Market 


Definition:  The  Recruit  Market  Decision  Parameter  estimates  the  total  number  of  males  who: 

1 .  live  in  the  area  of  the  proposed  relocation  site 

2.  Would  score  in  the  top  half  on  the  Armed  Forces  Qualification  Test  (AFQT) 

3.  Fall  into  the  desired  age  group  (17-29  years  old) 

Calculation:  This  Decision  Parameter  sums  the  entries  for  all  mental  categories  1  through  3 A, 
and  all  ethnic  groups  for  the  zip  codes  of  interest  in  the  Qualified  Military 
Available  (QMA)  file.  The  version  of  QMA  used  contains  only  the  estimates  for 
males  within  the  age  range  of  17  to  29. 

TOTAL_MARKET[Total  Non-Prior  Service  Personnel  from  the  Area] 

Units:  People 

Source  File:  QMA,  US_ZIPS(MapInfo) 

ACROPOLIS  Table(s):  NONE 

Queiy:  QMA(MapInfo) 

SELECT  LEFT$(ZIP,  5)  “ZIPCODE”,  MWCAT12,  MWCAT3A,  MBCAT12, 
MBCAT3A,  MHCAT12,  MHCAT3A 
FROM  QMA 

WHERE  Obj  Within  objAreaBuffer 
ORDER  BY  ZIP 

(Note:  objAreaBuffer  is  equal  to  300  miles) 

AREA_ZIPCODE(MapInfo) 

SELECT  ZIP_CODE 
FROM  US_ZIPS 
WHERE  Obj  Within  objAreaBuffer 
ORDER  BY  ZIP_CODE 

TOTAL_MARKET 

SELECT  SUM(MWCAT12+MWCAT3A+MBCAT12+MBCAT3A+ 
MHCAT12+MHCAT3A)  AS  TOTAL_MARKET 
FROM  QMA 

WHERE  QMA.ZIP  =  ANY  (SELCET  AREA_ZIPCODE.ZIP 

FROM  AREA_ZIPCODE) 
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Yield  Curve:  Approximately  half  of  a  typical  unit  of  100  reservists  is  filled  by  recruits  v^th  no 
prior  service.  Assuming  a  recruit  rate  of  0.25  percent,  there  must  be  at  least 
20,000  people  in  the  area  of  the  proposed  relocation  site  who  meet  all  of  the 
requirements  stated  above.  This  value  is  assigned  a  typical  utility  of  0.5.  As  the 
number  increases,  there  are  diminishing  returns.  The  market  begins  to  exceed  the 
personnel  demand  of  a  moving  unit  and  limited  recruiting  efforts  become 
marginally  less  effective. 


Max  Utility:  >250,000  Min  Utility:  0 
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Decision  Parameter  15.  Reassignments 

Definition:  The  Reassignments  Decision  Parameter  indicates  the  fraction  of  the  reservists 

assigned  to  the  moving  unit  who  currently  live  within  a  specified  distance  (50 
miles)  of  the  proposed  relocation  site 

Calculation:  This  Decision  Parameter  is  calculated  by  first  determining  all  zip  codes  that  lie 
within  a  specified  distance  of  the  proposed  relocation  site  (based  upon  zip  code 
centroid)  and  then  identifying  all  reservists  who  both  live  within  one  of  the 
identified  zip  codes  (based  upon  the  “ZIP”  field  of  the  G18CWE  file)  and  are 
assigned  to  the  moving  unit  (based  upon  the  “UIC”  field  of  the  G18CWE  file). 
Then  the  number  available  reassignments  is  divided  by  the  total  number  of 
reservists  assigned  to  the  moving  unit. 

TOTAL_RESERVISTS[Total  Number  of  Available  Reservists  from  the  Moving  Unit] 
UIC_TOTAL[Total  Number  of  Reservists  Assigned  Moving  Unit] 

Units:  Ratio 

Source  File:  G1 8CWE,  US_ZIPS(MapInfo) 

ACROPOLIS  Table(s):  G18Natl 

Query:  AREA_ZIPCODE(MapInfo) 

SELECT  ZIP_CODE 
FROM  US_ZIPS 
WHERE  Obj  Within  objAreaBuffer 
ORDER  BY  ZIP_CODE 

G18(MapInfo) 

SELECT  UIC,  LEFT$(ZIP,5)  “ZIPCODE”,  PRI  “MOS” 

FROM  G18CWE 

WHERE  Obj  Within  objG18Buffer  AND  PRI  o 
ORDER  BY  UIC,  ZIP 
INTO  G18 

Area_G18_ZIP 

SELECT  DISTINCT  UIC,  ZIPCODE,  COUNT(UIC)  AS  UIC_TOTAL 

FROM  G18 

GROUP  BY  UIC,  ZIPCODE 

ORDER  BY  UIC,  ZIPCODE 
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TOTAL_RESERVISTS 

SELECT  SUM(UIC_TOTAL)  AS  TOTAL_RESERVISTS 

FROM  Area_G18_ZIP 

WHERE  Area_Gl  8_ZIP.UIC  =  MovingUnit.UIC 

AND  Area_G18_ZIP.ZIPCODE  =  ANY  (SELECT  AREA_ZIPCODE.ZIP 

FROM  AREA_ZIPCODE) 


UIC_TOTAL 
SELECT  UIC_TOTAL 
FROM  G18Natl 

WHERE  G1 8Natl.UIC  =  MovingUnit.UIC 

Yield  Curve:  The  current  location  will  always  receive  a  utility  score  of  0.0  on  this  Decision 
Parameter.  For  relatively  close  relocation  sites,  this  function  was  made  to  be 
convex,  assigning  high  utility  values  to  alternatives  that  are  close  to  the  current 
location. 


0  Potential  reassignments  / 

Total  number  of  reservists 


Max  Utility;  1.0 


Min  Utility:  0.0 
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Decision  Parameter  16.  Distance  to  Area  Maintenance  Support  Activity 

Definition:  Distance  to  the  nearest  Area  Maintenance  Support  Activity  (AMS A)  is  calculated 

as  a  proxy  Decision  Parameter  for  response  time  and  support  quality. 

Calculation:  The  straight-line  distance  from  the  proposed  site  to  the  closest  AMSA  is 
calculated  using  a  geocoded  version  of  the  AMSA  file. 

DIST_AMSA[Determine  distance  to  nearest  AMSA  Site] 

Units:  Miles 

Source  Data:  AMSA 

ACROPOLIS  Table(s):  NONE 

Query:  DIST_AMSA(MapInfo) 

SELECT  * 

FROM  AMSA 

WHERE  Obj  Withing  ObjDistanceBuffer  into  TempRZA 
(Note:  ObjDistanceBuffer  is  equal  to  300  miles) 

SELECT  Distance((CentroidX(Obj),  CentroidY(Obj),  FacIDLat,  FacIDLong,  “mi”) 

FROM  TempAMSA 

ORDER  BY  Distance  INTO  TempAMSA.Dist 

Yield  Curve:  The  desirability  of  a  relocation  site  is  relatively  insensitive  to  small  changes  in 
distance  for  both  close  and  distant  AMSA  sites.  Little  degradation  in  service  is 
expected  if  the  AMSA  can  have  parts  and  technicians  on  site  within  a  couple 
hours  using  a  car  or  truck.  It  is  possible  that  a  trainer  that  breaks  down  in  the 
morning  may  be  operational  for  an  afternoon  training  session.  At  approximately 
200  miles  (assigned  a  0.5  utility)  it  starts  to  become  impractical  to  expect  same 
day  service  and  avoid  an  overnight  stay.  Eventually  it  becomes  necessary  to 
consider  flying  rather  than  driving  which  is  likely  to  further  reduce  the 
responsiveness  and  effectiveness  of  the  AMSA. 


Max  Utility:  0  Min  Utility:  >  500 
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Decision  Parameter  17.  Distance  to  Nearest  Equipment  Concentration  Site 

Definition:  Distance  to  the  nearest  Equipment  Concentration  Site  (ECS)  provides  an 

indication  of  the  training  time  that  must  be  used  to  travel  back  and  forth. 

Calculation:  The  straight-line  distance  from  the  proposed  site  to  the  closest  ECS  is  calculated 
using  a  geocoded  version  of  the  ECS  file. 

DIST_ECS[Determine  distance  to  nearest  ECS] 

Units:  Miles 

Source  Data:  ECS 

ACROPOLIS  Table(s):  NONE 

Query:  DIST_ECS(MapInfo) 

SELECT  * 

FROM  ECS 

WHERE  Obj  Withing  ObjDistanceBuffer  into  TempECS 
(Note:  ObjDistanceBuffer  is  equal  to  300  miles) 

SELECT  Distance((CentroidX(Obj),  CentroidY(Obj),  FacIDLat,  FacIDLong,  “mi”) 
FROM  TempECS 

ORDER  BY  Distance  INTO  TempECS. Dist 

Yield  Curve:  The  desirability  of  an  Equipment  Concentration  Site  is  relatively  insensitive  to 
small  changes  in  distance  for  both  close  and  distant  sites.  Typically,  a  site  that 
can  be  reached  within  an  hour  and  ten  minutes  is  not  significantly  less  desirable 
than  one  that  can  be  reached  in  ten  minutes.  An  hour  of  one-way  travel  time  is 
not  normally  considered  to  be  excessive  and  allows  for  most  of  the  time  to  be 
spent  training  on  a  one  day  training  exercise.  At  approximately  60  miles 
(assigned  a  0.5  utility)  it  starts  to  become  impractical  to  expect  useful  training  to 
be  conducted  on  a  day  trip  and  avoid  an  overnight  stay.  Eventujilly  it  beeomes 
necessary  to  consider  flying  rather  than  driving  whieh  is  likely  to  further  reduce 
the  desirability  of  the  ECS. 


Utility 


Miles 

Max  Utility:  0  Min  Utility:  >200 
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Decision  Parameter  18.  Facility  Weekends  Used 

Definition:  Facility  Weekend  Usage  provides  the  number  of  weekends  per  month  that  the 

facility  is  currently  in  use.  This  Decision  Parameter  treats  a  facility  as  a  limited 
resource  that  is  incrementally  depleted  as  more  units  are  assigned.  Sinee  most 
units  require  exclusive  use  of  the  facility  one  weekend  every  month,  the  number 
of  weekends  used  normally  corresponds  to  the  number  of  imits  assigned  and  is 
typically  limited  to  four. 

Calculation:  This  value  is  extracted  from  the  “RS_WKND_PM”  field  of  the  COMPLEX  file. 

WKND_USED  [Retrieve  Number  Weekends  Facility  Used  per  Month] 

Units:  Weekends  per  month 

Source  Data:  COMPLEX 

ACROPOLIS  Table(s):  COMPLEX_ 

Query:  WKND_USED 

SELECT  COMPLEX_.FAC_WKND_USED 
FROM  COMPLEX_ 

WHERE  COMPLEX_.FAC_ID  =  ProposedFacility.FAC_ID 

Yield  Curve:  Although  some  exceptions  exist,  a  typical  facility  offers  no  utility  to  a  relocating 
unit  if  all  four  weekends  are  already  being  used.  Although  most  facilities  with 
three  units  or  less  should  be  able  to  accommodate  a  new  unit  and  might  be  viewed 
as  having  equal  utility,  other  issues  such  as  full  time  administrative  space  and 
available  equipment  storage  space  make  a  facility  with  fewer  units  currently 
assigned  slightly  more  desirable. 


Max  Utility:  0  Min  Utility:  4 
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Decision  Parameter  19.  Available  MOS  from  Closing  Units 

Definition:  This  Decision  Parameter  provides  the  number  of  reservists  from  closing  units  in 

the  area  of  the  proposed  relocation  site  Avho  possess  a  Military  Occupational 
Specialty  (MOS)  needed  by  the  relocating  unit.  These  people  provide  a  preferred 
pool  of  trained  and  qualified  recruits. 

Calculation:  The  number  of  personnel  records  (from  the  G18CWE  file)  that  meet  all  the 
following  requirements  are  counted: 

1.  The  reservist  is  assigned  to  a  unit  that  is  scheduled  to  close  (a 
TIER=”5B”  entry  in  the  G17  file  is  used  to  produce  a  list  of  closing 
units). 

2.  The  reservist  lives  in  a  zip  code  in  the  area  of  the  proposed  relocation 
site. 

3.  The  reservist’s  primary  MOS  is  needed  by  the  moving  unit. 

If  the  three  MOS  groups  with  the  largest  number  of  members  in  the  moving  unit 
account  for  more  than  50  percent  of  the  total  unit  membership,  then  only  those 
three  MOS’s  are  considered.  Otherwise  all  MOS’s  required  by  the  moving  unit 
are  considered  as  an  MOS  of  interest. 

TOTAL_CLOS_MOS[Total  Number  of  Available  Reservists  from  Area  Closing  Units  with 

MOS’s  of  Interest] 


Units:  Number  of  people 

Source  File:  COMMAND  PLAND,  G17,  G1 8CWE,  GEOREF,  US_ZIPS(MapInfo) 
ACROPOLIS  Table(s):  CMDPLAN,  G1 7Natl,  G1 8Natl,  VALID_UIC 


Query:  Area-FACID  List(MapInfo) 

SELECT  FACJD  INTO  TempFACID 

FROM  GEOREF 

WHERE  Obj  Within  objAreaBuffer 

ORDER  BY  FACJD 

(Note:  objAreaBuffer  is  equal  to  300  miles) 

VALID_UIC 

SELECT  UIC,  FACJD,  UnitName,  City,  State,  Zip 
FROM  G17Natl 

WHERE  G1  TNatl.UIC  =  ANY  (SELECT  CMD_PLAN.UIC 

FROM  CMD_PLAN) 
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Area-UIC  List 

SELECT  DISTINCT  UIC  INTO  AREA_UIC 
FROM  VALIDUIC 

WHERE  VALID_UIC.FAC_ID  =  ANY  (SELECT  AREA_FACID.FAC_ID 

FROM  AREA_FACID) 


NoAssnxMOS 

SELECT  MOS,  COUNT(*)  AS  MOS_COUNT  INTO  NoAssnxMOS 
FROM  GlSNatl 

WHERE  G 1  SNatl.UIC  =  MovingUnit.UIC 

GROUP  BY  MOS 

ORDER  BY  COUNT(*)DESC 

MOS_TOTAL 

SELECT  SUM(MOS_COUNT)ASMOS_TOTAL 
FROM  NoAssnxMOS 

MOS_TOP3 

SELECT  TOP  3  MOS_COUNT 
FROM  NoAssnxMOS 

MOS_INTEREST 

IF  MOS_TOP3/MOS_TOTAL  <  50% 

SELECT  MOS  INTO  MOS_INTEREST 
FROM  NoAssnxMOS 
ORDER  BY  MOS 
IF  MOS_TOP3/MOS_TOTAL  >  50% 

SELECT  TOP  3  MOS  INTO  MOS_INTEREST 
FROM  NoAssnxMOS 
ORDER  BY  MOS 

AREA_CLOS_UIC 
SELECT  UIC 
FROM  G17Natl 
WHERE  G17Natl.TIER  =  “5B” 

AND  GlTNatl.UIC  =  ANY  (SELECT  AREA_UIC.UIC 

FROM  AREA_UIC) 


AREA_ZIPCODE(MapInfo) 
SELECT  ZIP_CODE  AS  ZIP 
FROM  US_ZIPS 
WHERE  Obj  Within  objAreaBuffer 
ORDER  BY  ZIP  CODE 
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G18(MapInfo) 

SELECT  UIC,  LEFT$(ZIP,5)  “ZIPCODE”,  PRI  “MOS” 

FROM  G18CWE 

WHERE  Obj  Within  objGl  8Buffer  AND  PRI  o 
ORDER  BY  UIC,  ZIP 
INTO  G18 

Area_G18_M0S 

SELECT  DISTINCT  UIC,  ZipCode,  MOS,  COUNT(UIC)  AS  UIC_TOTAL 
INTO  Area_G18_M0S 
FROM  G18 

GROUP  BY  UIC,  ZipCode,  MOS 
ORDER  BY  UIC,  ZipCode,  MOS 

Area_G18_ZIP 

SELECT  DISTINCT  UIC,  ZIPCODE,  COUNT(UIC)  AS  UIC_TOTAL 

FROM  G18 

GROUP  BY  UIC,  ZIPCODE 

ORDER  BY  UIC,  ZIPCODE 

TOTAL_CLOS_MOS 

SELECT  SUM(UIC_TOTAL)  AS  TOTAL_CLOS_MOS 
FROM  Area_G18_MOS 

WHERE  Area_Gl 8_MOS.MOS  =  ANY  (SELECT  MOS_INTEREST.MOS 

FROM  MOS_INTEREST) 

AND  Area_G18_ZIP.UIC  =  ANY  (SELECT  AREA_CLOS_UIC.UIC 

FROM  AREA_CLOS_UIC) 

AND  Area_G18_ZIP.ZIPCODE  =  ANY  (SELECT  AREA_ZIPCODE.ZIP 

FROM  AREA_ZIPCODE) 


Yield  Curve:  The  shape  of  this  function  assumes  diminishing  returns  on  the  number  of  transfers 
available.  Experience  suggests  for  an  average  unit  of  100  people,  that  it  is 
unusual  to  expect  more  than  a  third  of  the  members  to  transfer  from  closing  units 
with  the  proper  MOS.  Of  the  reservists  in  this  category,  only  half  typically 
transfer,  so  a  value  of  60  personnel  is  assigned  a  utility  of  0.9.  The  incremental 
value  added  by  each  additional  person  over  60  continues  to  drop  until  no  marginal 
gain  is  expected  over  250. 
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Decision  Parameter  20.  Available  MOS  IRR 


Definition;  This  Decision  Parameter  provides  the  number  of  Individual  Ready  Reserve 
members  who  live  in  the  area  of  the  proposed  relocation  site  and  who  possess  a 
Military  Occupational  Specialty  (MOS)  needed  by  the  relocating  unit.  These 
people  provide  a  preferred  pool  of  trained  recruits. 

Calculation:  The  number  of  IRR  members  who  possess  an  MOS  needed  by  the  moving  unit 
and  who  live  in  the  area  of  the  proposed  relocation  site  (based  upon  the  zip  code 
of  their  home  of  record  in  the  IRR  file)  are  counted.  If  the  three  MOS  groups  with 
the  largest  number  of  members  in  the  moving  unit  account  for  more  than  50 
percent  of  the  total  unit  membership,  then  only  those  three  MOSs  are  considered. 
Otherwise  all  MOSs  required  by  the  moving  unit  are  considered  as  an  MOS  of 
interest. 

TOTAL_IRR_MOS[Total  Number  of  Available  Reservists  from  the  IRR  with  MOS’s  of 

Interest] 


Units:  Number  of  People 


Source  File:  IRR,G18CWE 
ACROPOLIS  Table(s):  GlSNatl, 


Query:  NoAssnxMOS 

SELECT  MOS,  COUNT(*)  AS  MOS_COUNT  INTO  NoAssnxMOS 
FROM  GlSNatl 

WHERE  G1  SNatl.UIC  =  MovingUnit.UIC 

GROUP BY  MOS 

ORDER  BY  COUNT(*)DESC 

MOS_TOTAL 

SELECT  SUM(MOS_COUNT)  AS  MOS_TOTAL 
FROM  NoAssnxMOS 

MOS_TOP3 

SELECT  TOP  3  MOS_COUNT 
FROM  NoAssnxMOS 

MOS_INTEREST 

IF  MOS_TOP3/MOS_TOTAL  <  50% 

SELECT  MOS  INTO  MOS_INTEREST 
FROM  NoAssnxMOS 
ORDER  BY  MOS 
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IF  M0S_T0P3/M0S_T0TAL  >  50% 

SELECT  TOP  3  MOS  INTO  MOS_INTEREST 
FROM  NoAssnxMOS 
ORDER  BY  MOS 

IRR(MapInfo) 

SELECT  ZIPC  “ZIP”,  LEFT$(PMOS,  3)  “MOS” 

FROM  IRR 

WHERE  Obj  Within  obj  AreaBuffer  and  ZIPC  o  “”  AND  PMOS  o  “” 

ORDER  BY  ZIPC 
INTO  IRR 

TOTAL_IRR_MOS 

SELECT  SUM(UIC_TOTAL)  AS  TOTAL_CLOS_MOS 
FROM  IRR 

WHERE  IRR.MOS  =  ANY  (SELECT  MOS_INTEREST.MOS 

FROM  MOSJNTEREST) 

Yield  Curve:  IRR  members  represent  preferred  recruits  for  less  than  half  of  the  positions  of  a 
typical  moving  unit  (approximately  40  out  of  100)  because  of  issues  such  as 
seniority  and  changes  in  the  skills  associated  with  an  MOS.  The  success  rate  of 
recruiting  IRR  members  is  approximately  1  out  of  100,  so  4000  IRR  members  in 
the  area  of  the  relocation  site  are  required  to  provide  sufficient  market  to  fill  the 
40  positions.  The  value  of  4000  is  assigned  the  average  utility  value  of  0.5.  As 
the  IRR  market  increases  it  exceeds  the  needs  of  the  moving  unit  and  makes  the 
limited  recruiting  efforts  marginally  less  effective. 


Max  Utility:  >25,000  Min  Utility:  0 
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APPENDIX  C.  CONCEPTUALIZATION  PHASE  ARTIFACTS. 


This  appendix  contains  the  artifacts  that  were  documented  upon  completion  of  the 
Concept-to-Code  (C2C)  Conceptualization  Phase. 


Index 

1 .  Conceptual  Overview  Diagram . 171 

2.  ARIES  Data  Flow  Diagram . 173 

3 .  User  Inteface  Interim  Layout . 175 

4.  User  Interface  Final  Layout . 177 
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ARIES  Process  Flow  Diagram. 
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User  Interface  Interim  Layout. 
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APPENDIX  D.  ARIES  SDSS  CODE  LISTINGS 


This  appendix  contains  the  detailed  code  listings  of  each  Visual  and  Map  Basic  module 
that  comprises  the  ARIES  SDSS  prototype  application. 


Index 

Module  1.  SUBMAIN  PROCEDURE . 181 

Module  2.  SDSS  USER  INTERFACE . 183 

Module  3.  ARIES  PUBLIC  DECLARATIONS . . 213 

Module  4.  ARIES  PROCEDURES  LIBRARY . 221 

Module  5.  OLE  PROCEDURES  LIBRARY . .231 

Module  6.  OLE  OBJECT  CLASS  DEFINITION . 239 

Module  7.  MAPBASIC  PUBLIC  DECLARATIONS . 243 

Module  8.  SPATIAL  SELECTION  PROGRAM . 257 
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Module  1.  SUBMAIN  PROCEDURE 


Purpose:  Submain  Procedure  immediately  executes  upon  ARIES  application  loading  in 

memory.  It  is  a  standard  Visual  Basic  initialization  procedure.  For  the  purposes 
of  the  ARIES  SDSS,  the  procedure  loads  the  splash  screen  for  30  seconds, 
initializes  all  OLE  connections  with  Mapinfo  components  and  displays  the  main 
SDSS  User  Interface  form. 

Source  Type:  Visual  Basic  for  Applications 

Source  File:  SUBMAIN.BAS 

Code  Listing: 


Attribute  VB_Name  =  ”Subriain” 

Option  Explicit 

'Allocate  Module  Variables 
Public  bValidUIC  As  Boolean 
Public  bS(3L(2uery])one  As  Boolean 
Public  bLDUactive  As  Boolean 
Public  bGEOREF_Exists  As  Boolean 

Public  bMapfiueryActi ve  As  Boolean 
Public  bMapInf oRunning  As  Boolean 
Public  bMapBasicRunning  As  Boolean 

Public  iPropFacIDctr  As  Integer 
Public  iProgressIndicator  As  Integer 
Public  iStatusBarMax  As  Integer 

'UinAPI3B  window  handles 
Public  iLDIilwinlO  As  Long 
Public  iMapInf oblinlO  As  Long 

Public  aFacIIXM)  As  String  *  S 

Public  c(2ueryStartTime  As  String  *  fl 
Public  cProcName  As  String 

'Allocates  Aries  Measures  Table 
Public  cMovUic  As  MovingUnit_Type 

'Allocate  Database  Objects 
Public  dbAcropolis  As  Database 
Public  dbTeliko  As  Database 
Public  dbkiorkspc  As  Workspace 

Public  objExcel  As  Object 
Public  objGeoSelect  As  Object 
Public  objGeofiuery  As  Object 
Public  objCallback  As  Object 


Public  Sub  MainO 

cProcName  =  ”SUB_MAIN” 

On  Error  GoTo  EH_SubMain 
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Set  objExcel  =  Nothing 
Set  objGeoSelect  =  Nothing 
Set  objGeo(3uery  =  Nothing 
Set  objCallback  =  Nothing 

'Initialize  all  Boolean  FLAGS  to  Default  value- 
bValidUIC  =  False 

bLDUactive  =  False  'LDli)  Activation  Flag 

bS(3Lr3ueryDone  =  False 
bGEOREF_Exists  =  True 

bflapflueryActi ve  =  False  'MapBasic  Activation  Flag 

bflapBasicRunning  =  False 
bHapInf oRunning  =  False 

'Initialize  API  hUnd  ID  variables 
iLDUwinlD  =  D 
iflapinf  oWinlD  =  0 

'Commence  loading  ARIES  Application 
Load  f rmSplashScrn 

'bLDWactive  =  OpenLDlilob  ject 
'Call  ImportLDIildata 
'Call  ViewLDliimatrix 

Exit  Sub 

EH_Subnain:  'Submain  Error  Handler 

Select  Case  Err-Number 

Case  ERR_0b jectUnloaded 

Call  DisplayHessage (OLEf aileddSGn  vbExclamationi  vbOKOnlyT 
conOLEcaption) 

End 

Case  Else  'Trap  all  other  Errors  a  Report 
Call  OutputERROR_L06 
Resume  Next 

End  Select 
End  Sub 

Public  Sub  DisplayUserInterf ace ( ) 

cProcName  =  "Display_User_Interf ace" 

With  f rmAriesflain 
■Visible  =  True 
-UindowState  =  vbdaximized 
.  Show 
End  With 

Screen - MousePointer  =  vbDefault 
End  Sub 
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Module!.  SDSS  USER  INTERFACE 


Purpose:  Contains  all  procedures,  business  rules,  and  logic  for  controlling  the  ARIES  U/I 

Source  Type:  Visual  Basic  for  Applications 
Source  File:  USERINTERFACE.FRM 
Code  Listing: 


Attribute  VB_Name  =  "f rmAriesHain" 

Attribute  VB_Creatable  =  False 
Attribute  VB_Exposed  =  False 

Option  Explicit 

Private  Sub  mnuFOpen_Click () 

Dim  iLDIiJ_hUnd  As  Long 

On  Error  GoTo  EH_FileOpen 

dlgLOlilFiler  .Flags  =  cdlOFNPathHustExist  +  cdlOFNFileMustExist 
dlgLOUFiler .  InitOir  =  App.Path  &  FILE„LI>U__ArchiveDir 
dlgLOlilFi ler .  f  i lename  =  vbNullString 
dlgLOUFiler . ShowOpen 

iL0U__hUnd  =  FindUindow( Class__L0U i  vbNullString) 

If  iLOU^hUnd  =  D  Then  Call  OpenLOUob ject 

ShowUindow  iLOU^hUndi  SU^Minimum 
ShowUindow  iLOU_hUndi  SU_Normal 

SendKeys  "JcFN"-.  True 

SendKeys  ")cF0"t  True 

SendKeys  dlgLOUFi ler . fi lename i  True 

SendKeys  "CENTER!"-.  True 

OoEvents 

SendKeys  True 

Exit  Sub 
EH_FileOpen : 

If  Not  Err. Number  =  cdlCancel  Then  Call  0utputERR0R_L0G 
End  Sub 

Private  Sub  mnuFSave_Click ( ) 

Oim  iL0U_hUnd  As  Long 

On  Error  GoTo  EH_FileSave 

dlgLOUFiler. Flags  =  cdlOFNPathMustExist 

dlgLOUFi ler . InitOir  =  App-Path  a  FILE_LOU_ArchiveOir 

dlgLOUFiler . filename  =  vbNullString 

dlgLOUFiler. ShowSave 

iL0U_hUnd  =  FindUindow ( Class_L0U vbNullString) 

If  iL0U_hUnd  =  D  Then  Call  OpenLOUob ject 

ShowUindouf  iLOU_hUndi  SUJinimum 
ShowUindow  iLOU^hUnd-.  SU_Normal 
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SendKeys  True 

SendKeys  dlgLDWFiler- f ilenamen  True 
SendKeys  "{ENTER}”-,  True 
DoEvents 

AppActivate  ARIES_Application 
Exit  Sub 

EH_Fi leSave : 

If  Not  Err. Number  =  cdlCancel  Then  Call  0utputERR0R__L0G 
End  Sub 

Private  Sub  mnuFCloseLDU^Click ( ) 

If  Verif yLDUob jectConnection (LDUactiveMSG)  Then 
SendKeys  "^FX"-,  True 
DoEvents 

mnuVImport - Enabled  =  True 
tbararies . Buttons ("import") . Enabled  =  True 
End  If 
End  Sub 

Private  Sub  mnuFCloseriap_Cl  ick  ( ) 

Dim  iMapInf o__hliJnd  As  Long 

iflaplnf  o_hlilnd  =  Findlilindow  ( Class_f1aplnf  o vbNul  IStr ing ) 

If  inapInfo_hlilnd  =  D  Then 

Call  Displayflessage  ( APIf  ailedfISGi  vbCriticali  vbOKOnlyi 
Else 

btlaplnf  oRunning  =  False 
ShowUindow  iflaplnf o^hUnd-,  SW^dinimum 
ShowWindow  iMapInf o_hUnd SU_Normal 

SendKeys  "/:FX"t  True 
End  If 
End  Sub 

Private  Sub  mnuFSetup_Click ( ) 

Dim  iLDli!_hbJnd  As  Long 

iLDIi)_hUnd  =  FindUindowCClass^LDIili  vbNul IString ) 

If  iLDU_hlilnd  =  □  Then  Call  OpenLDbJob ject 

ShowliJindow  iLDb)__hli)ndi  SU_ninimum 
Showlilindow  iLDli)_hli)nd SU^Normal 

SendKeys  "/IFR"-,  True 
End  Sub 

Private  Sub  mnuFExit_Cl ick ( ) 

Cali  cmdExitBtn_Click 
End  Sub 

Private  Sub  mnuVHier_Click ( ) 

If  Not  mnuVImport . Enabled  Then 

If  Verif yLDlilob jectConnection( APIf aileddSG)  Then 
SendKeys  True 

SendKeys  "^HCdounlG" True 
End  If 
Else 

Call  Displaydessage (NoFaci lityComparednSG 1  vbinf ormation 
vbOKOnly-i  conAPIcapt ion) 

End  If 
End  Sub 

Private  Sub  mnuVUatr ix_Click ( ) 
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conAPIcaption) 


If  VerifyLDWob jectConnection(APIfailednSG)  Then 
SendKeys  True 

DoEvents 
End  If 
End  Sub 

Private  Sub  mnuVSensitivity_Cl ick ( ) 

If  VerifyLDliiob jectConnection(APIfailednSG)  Then 
SendKeys  True 

End  If 
End  Sub 

Private  Sub  mnuVStackBar_Cl ick ( ) 

If  VerifyLDUob jectConnectionCAPIfailedMSG)  Then 
SendKeys  ”/CSB”t  True 
DoEvents 

SendKeys  True 

End  If 

End  Sub 

Private  Sub  mnuVIinport__Cl ick ( ) 

If  bS(2L(3ueryPone  Then 

tbararies -Buttons ("import”) -Enabled  =  False 
mnuVImport - Enabled  =  False 
fraLDliIcntrl  -  Visible  =  False 

bLDUactive  =  OpenLDUob ject 
Call  ImportLDIildata 
Call  ViewLDWmatrix 
Else 

Call  Displayhessage (NoFacilityComparednSG-i  vbinf ormationi  _ 
vbOKOnlyn  conAPIcaption) 

End  If 
End  Sub 

Private  Sub  mnuRPrintAll_Cl ick () 

Dim  illsgBxResponse  As  Byte 

iHsgBxResponse  =  DisplayMessage (PrinterReadyflSGi  vbExclamation-i 
vbOKi  conAPIcaption) 

If  irisgBxResponse  =  vbOK  Then 

If  Verif  yLDUob  jectConnection  (LDIilactiveriSG)  Then 
Call  TimeDelay (Time$ ( ) T  B) 

Call  ActivateLDIilReports 
AppActivate  ARIES__Application 
End  If 
End  If 
End  Sub 

Private  Sub  txtPropFacID_Change ( ) 

Uith  txtPropFacID 

If  (-Text  =  ””)  Or  (Len(.Text)  <  S)  Then 
-Text  =  -ListCD) 

End  If 
End  With 

End  Sub 

Private  Sub  cboUIC_Change ( ) 

Uith  cboUIC 

If  (-Text  =  ””)  Or  (Len(-Text)  <  b)  Then 
-Text  =  . ListCD) 
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End  If 
End  With 


End  Sub 

Private  Sub  cmdAccGptBtn_Click ( ) 

Dim  iFacIDctr  As  Byte 
Dim  Index  As  Byte 
Dim  i  As  Byte 

Dim  iConf irmResponse  As  Byte 
Dim  cfisg  As  String 

If  bValidUIC  Then 

iFacIDctr  =  CountFacIDs 
For  i  =  D  To  3 

If  txtFacID(i) .Tag  =  "NOT  USED"  Then 
Index  =  i 
Exit  For 
End  If 
Next  i 

If  iFacIDctr  <  M  Then 

txtFacID(Index) ^Text  =  txtPropFacID . Text 
Else 

cMsg  =  "Maximum  number  of  Facilities  Selected-"  &  vbCr  &  vbCr  8;  _ 
"Do  You  Wish  to  Delete  Facility  -C"  &  txtFacID (3)  . Text  S  _ 

"}f" 

iConf irmResponse  =  MsgBox(cMsgn  vb(2uestion  +  vbYesNoi 
conFacilityErr or Caption) 

If  iConf irmResponse  =  vbYes  Then 

txtFacID (3 )- Text  =  txtPropFacID . Tex t 
End  If 
End  If 

Else 

If  Not  cboUIC-Text  =  "-NONE-"  Then 
txtMovUIC . Text  =  cboUIC-Text 
Else 

ciisg  =  "Facility  I"  &  txtPropFacID  &  ">  has  no  Units  Assigned." 
Call  DisplayMessage  ( cMsg T  vbExclamation-i  vbOKOnly-i  conUICcaption) 
End  If 
End  If 
End  Sub 

Private  Sub  cmdAriesBtn_Click ( ) 

Call  CompareFacilities 
End  Sub 

Private  Sub  cmdClGarBtn_Click () 

'Reset  all  controls  and  elements  of  the  User  Interface  to  Defaults 

Call  InitFacilityElements  'Reset  controls  to  Defaults 

Call  InitMenuBar 

Call  InitToolBar 

Call  Ini tAriesControls 

Call  InitStatusBar 

Call  InitGIStreeview 

Call  Traff icLight(vbRed) 

If  AriesStatusBar -PanelsCS) -Text  =  "Custom  Tool  :  FacID  Info"  Then 
cmdAcceptBtn - Enabled  =  True 
End  If 

bMapBasicRunning  =  False 
bSt3L(3ueryDone  =  False 


txtMovUIC -SetFocus 
Refresh 
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'Set  cursor  at  MOVUIC  txtbox 


End  Sub 


Public  Sub  cmdExitBtn_Click () 
cProcName  =  "Exi tBtn_Cl ick" 

Dim  iConf irmResponse  As  Byte  'HSGBox  Response  Variable 

If  bS(3L(2ueryDone  Then 

'Display  Confirm  CompactDatabase  Hessagebox 
iConf  irmResponse  =  MsgBox  (CompactDatabaseflSG t  _ 

vb(2uestion  +  vbYesNo  +  vbApplicationHodal  n  conFileCaption) 

'Evaluate  User  Response 

If  iConf irmResponse  =  vbYes  Then  'Compact  Database 
Call  CompactAriesDataBase 
End  If 
End  If 

If  Not  (ob jGeoSelect  Is  Nothing)  Then 
ob jGeoSelect • SetCallback  Nothing 
End  If 

Set  objGeoSelect  =  Nothing 
Set  objCallback  =  Nothing 
Set  objGeofluery  =  Nothing 
Set  objExcel  =  Nothing 

Set  dbAcropolis  =  Nothing 
Set  dbTeliko  =  Nothing 

Unload  Me  'Close  User  Interface 

End  Sub 

Private  Sub  cmdYesBtn_Click ( ) 

Call  mnuVImport_Click 
End  Sub 

Private  Sub  cmdNoBtn_Cl ick ( ) 

Dim  iConf irmResponse  As  Byte 
Dim  cDsg  As  String 

cUsg  =  ”Do  You  Uish  to  Discard  Facility  Compar isonsf ” 
iConf  irmResponse  =  HsgBox  (cfisg  t  vb(2uestion  +  vbYesNon  conS(2Lcaption ) 
If  iConf irmResponse  =  vbYes  Then 
fraLDliIcntrl .  Visible  =  False 
Call  InitHeasuresGrid (D) 

Call  cmdClearBtn_Click 
End  If 
End  Sub 

Private  Sub  spinFacIDbtn_SpinDown ( ) 

Dim  iComboBoxMax  As  Integer 

lilith  tx'tPropFacID 

iComboBoxIlax  =  -ListCount  -  1 
If  Not  ( iPropFacIDctr  =  iComboBoxMax )  Then 
iPropFacIDctr  =  iPropFacIDctr  +  1 
-Text  =  -List ( iPropFacIDctr) 

Call  LoadPropFaci 1 ityUICBox ( -Text) 

Call  DisplayPropFacilityUnitNames 
End  If 
End  With 
End  Sub 

Private  Sub  spinFacIDbtn_SpinUp ( ) 

With  txtPropFacID 

If  Not  iPropFacIDctr  =  Q  Then 
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iPropFacIDctr  =  iPropFacIDctr  -  1 
•Text  =  -List (iPropFacIDctr) 

Call  LoadPropFaci lityUICBox ( -  Text) 
Call  DisplayPropFacili tyUni tNames 
End  If 
End  With 
End  Sub 


Private  Sub  tbar Aries_ButtonClick (ByVal  Button  As  Button) 

Dim  iLDUhUnd  As  Long  'API  window  handler 

Dim  iMsgBxResponse  As  Byte  'Messagebox  response  variable 


Select  Case  Button-Key 
Case  "selector” 

objGeoSelect-Runflenu Command  n_T00LS_SELECT0R 
AriesStatusBar-Panels(5) -Text  =  "Maplnfo  Tool  :  Selector" 

Case  "grabber" 

ob jGeoSelect  -RunflenuCommand  ri_TOOLS_RECENTER 
AriesStatusBar-Panels(S) -Text  =  "Haplnfo  Tool  :  Grabber" 

Case  "expand" 

ob jGeoSelect - RunflenuCommand  ri_T00LS_EXPAND 
AriesStatusBar.Panels(S) -Text  =  "Maplnfo  Tool  :  Zoom-In" 


Case  "shrink" 

objGeoSelect- RunHenuCommand  M_T00LS_SHRINK 
AriesStatusBar-Panels(S) -Text  =  "Maplnfo  Tool  :  Zoom-Out" 


Case  "infotool" 

ob jGeoSe lect - Do  "Run  Menu  Command  ID  5D1" 

AriesStatusBar - Panels (5) -  Text  =  "Custom  Tool  :  FacID  Info" 
pnlFacilitylnfo-Enabled  =  True 
cboUIC - Visible  =  True 
cboUIC -  Clear 

txtPropFacID - Visible  =  True 
txtPropFacID - Clear 
cmdAcceptBtn - Enabled  =  True 


Case  "mapinfo" 

If  Not  bflapinf oRunning  Then 

iflapinf olilinID  =  Shell  (FILEJapInfon  vbNormalFocus ) 

SendKeys  "-"i  True 
SendKeys  ")iFL"T  True 

ihaplnf olilinID  =  Findlj)indow(Class_11apInf Ot  vbNul IString ) 

If  iMapInf olilinID  =  D  Then 

Call  Displayflessage ( APIfailedflSGi  vbCriticali  vbOKOnlyi  _ 
conAPIcaption) 

End  If 

bflapinf  oRunning  =  True 
mnuFCloseflap-Enabled  =  True 
Else 

ShowUindow  iflapinf oUinlD i  Sliljinimum 
Showlilindow  iflapinf oblinlD i  Slil„Normal 
SendKeys  ">:FX"-i  True 
bflapinf  oRunning  =  False 
mnuFCloseflap  -  Enabled  =  False 
End  If 


Case  "Idw" 

iLDUhlilnd  =  Findli)indow(Class_LDlil-i  vbNullString ) 

If  iLDUhUnd  =  □  Then 

bLDUactive  =  OpenLDUob ject 
Else 

iMsgBxResponse  =  Displayflessage  (LDUresetfISG n  vbtSuestioni  vbOKT 
conAPIcaption) 

If  iMsgBxResponse  =  vbOK  Then 
Call  ResetLDUob ject 
AppActivate  ARIES_Appl ication 
tbararies -Buttons ("import") -Enabled  =  True 
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fraLDWcntrl • Visible  =  True 
mnuVImport • Enabled  =  True 
End  If 
End  If 

Case  "import” 

Call  mnuVImport_Click 

Case  "file" 

Case  "report" 

Call  mnuRPrintAll_Click 

Case  "matrix" 

Call  mnuVriatrix_Click 

Case  "hierarchy" 

Call  mnuVHier_Cl ick 

Case  "dynamic" 

Call  mnuVSensitivity_Click 

Case  "stacked" 

Call  mnuVStackBar_Cl ick 

Case  "about" 

End  Select 
End  Sub 

Private  Sub  cmdClearBtn_GotFocus () 

'Display  CLEAR  button  hint  on  main  status  bar 
AriesStatusBar.Panels(l) .Text  =  ClearButtonMSG 
End  Sub 

Private  Sub  cmdAriesBtn_GotFocus ( ) 

'Display  GENERATE  button  hint  on  main  status  bar 
AriesStatusBar  -  Panels  (1)  .  Text  =  LaunchAriesfISG 
End  Sub 

Private  Sub  cmdExitBtn_GotFocus () 

'Display  EXIT  Button  hint  on  main  status  bar 
AriesStatusBar - Panels ( 1) -  Text  =  ExitButtonMSG 
End  Sub 

Private  Sub  txtHo vUIC_GotFocus ( ) 

AriesStatusBar. Panels(l) .Text  =  flovUICstatbarnSG 
End  Sub 

Private  Sub  txtFacID_GotFocus ( Index  As  Integer) 

AriesStatusBar. Panels(l) .Text  =  Faci lityStatbarHSG  &  CStrCIndex  +  1) 
IstbxFacID(Index) .Visible  =  True 
End  Sub 

Private  Sub  txtMovUIC^LostFocus ( ) 

If  (Len(txtnovUIC)  =  D)  And  txtMovUIC . Tag  =  "VALID"  Then 
Call  TrafficLight(vbRed) 
bValidUIC  =  False 
txtnovUIC.Tag  =  "NOT  USED" 

IstbxMovUIC. Clear 
End  If 
End  Sub 

Private  Sub  txtFacID_LostFocus ( Index  As  Integer) 

Dim  iFacIDctr  As  Byte 
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If  (Len  (txtFacID  (Index) )  =  D)  And  txtFacID  (Index )- Tag  =  ”VALII>”  Then 
txtFacID (Index) . Tag  =  "NOT  USEO" 

IstbxFacIO (Index ). Clear 

IstbxFacIOdndex) -Addltem  "*  *  DELETED  *  *" 

End  If 

iFacIDctr  =  CountFacIDs 

If  iFacIDctr  =  D  And  txtMovUIC . Tag  =  "VALID"  Then 
Call  Traf f icLight ( vbYel low) 

Elself  txtMovUIC. Tag  =  "NOT  USED"  Then 
Call  TrafficLight(vbRed) 

End  If 
End  Sub 

Private  Sub  txtFacID_Change ( Index  As  Integer) 

Dim  bValidFacID  As  Boolean 

Dim  bValidUnit  As  Boolean 

Dim  cFacID  As  String  *  5 

Dim  cMsgText  As  String 

Dim  rs Val idateFacID  As  Recordset 

Dim  rsVal idateUnit  As  Recordset 

cMsgText  =  "" 
bValidFacID  =  False 
bValidUnit  =  False 

'Open  Validation  Table 

Set  rsVal idateFacID  =  dbAcropolis -OpenRecordset (Tbl_ValidateUICn  dbOpenTable-i 
dbReadOnly ) 

rsValidateFacID. Index  =  "FACID" 

If  bGEOREF^Exists  Then 

Set  rsVal idateUnit  =  dbAcropolis-OpenRecordset (Tbl_ValidateUniti 
dbOpenTablei  dbReadOnly) 

rsVal idateUnit . Index  =  "FACID" 

End  If 

'Automatically  determine  if  FACID  entered 
If  Len ( txtFacID ( Index ) )  =  5  Then 
cFacID  =  txtFacID (Index ).  Text 

bValidFacID  =  Val idateFacID ( cFacID t  rsValidateFacID) 

If  bGEOREF_Exists  Then 

bValidUnit  =  ValidateFacID (cFacID t  rsValidateUnit) 

End  If 

If  bValidFacID  Or  bValidUnit  Then  'Valid  FACID  exists 

If  bValidFacID  Then 

Call  LoadFacilityListBox (Indexi  rsValidateFacIDi  □) 

Else 

Call  LoadFacilityListBox (Indexn  rsVal idateUni t n  1) 

End  If 

aFacIDdndex  +  1)  =  cFacID 
txtFacID(Index) .Tag  =  "VALID" 

If  Not  (Index  =  3)  Then  'Prep  next  Facility  Frame 

Call  Initial izeFaci 1 ityFrame ( Index  +  1) 

Call  Traf f icLight (vbGreen) 

Else  'Last  Facility  Frame  used 

cmdAriesBtn . SetFocus 
End  If 

Else  'Facility  ID  invalid 

cMsgText  =  "FacID:  -C"  &  cFacID  a  FacIDinval idMSG 
Call  DisplayMessage ( cMsgTexti  vbinf ormation t  vbOKOnlyi 
conFacilityErrorCaption) 

txtFacID(Index) -Text  =  "" 
txtFacID(Index) -Tag  =  "NOT  USED" 

End  If 
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Else 

AriesStatusBar - Panels (1) • Text  =  FacIDlengthMSG 
End  If 

'Delete  Recordset  Object 

rsValidateFacID . Close 

Set  rsValidateFacID  =  Nothing 

rsVal idateUnit . Close 

Set  rsVal idateUnit  =  Nothing 

End  Sub 

Private  Sub  txtHovUIC^Change ( ) 
cProcName  =  ”TXTnOVUIC_CHANGE" 

Dim  cflsgText  As  String 

cNsgText  =  ”” 
bValidUIC  =  False 

If  Len ( txtMovUIC)  =  b  Then 

cMovUic-UIC  =  txtdovUIC-Text 
bValidUIC  =  Val idatedo vUIC ( cdovUic . UIC) 

If  bValidUIC  Then 

aFacID(D)  =  cdovUic . FacID 
Call  LoaddovUIClistbox (cdovUic) 

Call  InitializeFacilityFrame (0) 
cmdClearBtn - Enabled  =  True 
txtdovUIC-Tag  =  ”VALID^ 

'Set  the  appropiate  data  integrity  light 
If  Not  txtFacID(D) .Tag  =  "VALID”  Then 
Call  Traf f icLight (vbYellow) 

Else 

Call  Traf f icLight( vbGreen) 


Else  'Unit  ID  Code  invalid 

cdsgText  =  "UIC:  I”  &  cdovUic-UIC  &  dovUICinvaliddSG 

Call  Displaydessage  (cdsgText  1  vbinf  ormationn  vbOKOnly-i  conUICcaption) 
txtdovUIC-Text  = 
txtdovUIC.Tag  =  "NOT  USED" 

End  If 

Else 

AriesStatusBar - Panels (1) - Text  =  dovUIClengthdSG 
End  If 

End  Sub 

Private  Sub  txtFacID_KeyPress (Index  As  Integeri  KeyAscii  As  Integer) 

KeyAscii  =  KeyUpperNumeric (KeyAscii ) 

End  Sub 

Private  Sub  txtdovUIC_KeyPress (KeyAsci i  As  Integer) 

KeyAscii  =  KeyUpperNumeric(KeyAscii ) 

End  Sub 

Private  Function  CountFacIDs ( )  As  Byte 

Dim  i  As  Byte  'Loop  Variable 

CountFacIDs  =  0  'Initialize  function 

For  i  =  0  To  3  'Loop  thru  Facility  choices 

'Evaluate  Facility  Frame  TAG  field  for  Confirmed  Selections 
If  (txtFacID(i)  .Tag  =  "VALID")  Then 

CountFacIDs  =  CountFacIDs  +  1  'increment  counter 
End  If 
Next  i 
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End  Function 


Private  Sub  Form_Load() 

'Establish  DEFAULT  position  for  User  interface 
(le-Top  =  □ 

Me-Left  =  □ 

'Initialize  Acropolis  Database 

Set  dbUorkspc  =  DBEngine  -  Workspaces (□) 

Set  dbAcropolis  =  dbUorkspc . OpenDatabase ( App - Path  8;  FILE_Acropol is ) 

'Set  dbTeliko  =  dbliJorkspc .  OpenDatabase  ( App  .  Path  &  FILE_Teliko) 

Set  dbfleasures  =  Workspaces (0) • OpenDatabase (App . Path  &  DB^HEASURES ) 

Set  rslleasures  =  dbdeasures . OpenRecordset ( "fleasure  Values'*!  dbOpenTable) 
rstleasures  .  Index  =  ''FAC_ID” 

'Set  rsProblems  =  dbfleasures  -  OpenRecordset  ("Problems''!  dbOpenTable) 

'Initialize  the  USER  INTERFACE  and  Form  Controls 
Call  InitrienuBar 
Call  InitToolBar 
Call  Initflaps 

Call  InitFacilityInf oPanel 

Call  InitFacilityElements  'Initialize  Default  values 

Call  InitGIStreeview 

Call  Traf f icLight ( vbRed) 

Call  InitAriesControls 
Call  InitStatusBar 

Me-Show  'Display  form  to  User 

fie  .  WindowState  =  vbfiaximized 

Refresh 

Screen  -  flousePointer  =  vbDefault  'reset  mousepointer  to  arrow 

txtflovUIC •  SetFocus  'set  cursor  at  flOVUIC  txtbox 

End  Sub 

Private  Sub  Ini tial i zeFaci 1 i tyFrame ( By Val  Index  As  Integer) 
cProcName  =  "INITIALIZE^FACILITY^FRAnE" 

If  Not  Index  =  M  Then 

fraFaci 1 ity ( Index ). Enabled  =  True 
With  txtFacID ( Index ) 

■Visible  =  True 
-Enabled  =  True 
- SetFocus 
End  With 
End  If 
End  Sub 

Private  Sub  InitflenuBar ( ) 

cProcName  =  "INIT_f1ENU_BAR'' 

mnuVImport • Enabled  =  True 
mnuFCloseLDW - Enabled  =  True 

End  Sub 

Private  Sub  InitToolBar ( ) 

cProcName  =  "INIT^TOOL^BAR" 

tbararies - Buttons ("import”) -  Enabled  =  True 
tbararies -Buttons ("report”) -Enabled  =  True 
tbararies - Buttons ("matrix") -  Enabled  =  True 
tbararies - Buttons ("hierarchy") -  Enabled  =  True 
tbararies -Buttons ("dynamic") -Enabled  =  True 
tbararies -Buttons ("stacked") -Enabled  =  True 
End  Sub 
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Private  Sub  InitdapsO 

cProcName  =  "INITJAPS” 

Dim  bflapSe lectActi ve  As  Boolean 

'Load  dapinfo  Objects  for  Geofluery  Display 

bdaptSueryActive  =  ConnectOLEob ject (ob jGeo^uery t  ”dapinfo • Application") 

If  bdap(3ueryActive  Then  'Ensure  Application  loaded 

ob jGeofluery ■ Do  "Set  Application  Window  "  S;  pictdapfiueryFrame -hwnd 
ob j6eoi3uery « Do  "Set  Next  Document  Parent  "  a  pictdapflueryPrame - hwnd  a  " 
Style  1  " 

End  If 

'Load  dapinfo  Objects  for  GeoSelect  Display 

bdapSelectActi ve  =  ConnectOLEob ject (ob jGeoSelecti  "dapinfo . Application") 

If  bdapSelectActive  Then  'Ensure  Application  loaded 

ob jGeoSelect . Do  "Set  Application  Window  "  a  pictdapSelectFrame - hwnd 
ob jGeoSelect . Do  "Set  Next  Document  Parent  "  a  pictdapSelectFrame . hwnd  a  " 
Style  1  " 

End  If 

'Create  an  Instance  of  the  OLE  Callback  Object 
Set  objCallback  =  New  clsOLECallback 
objGeoSelect-SetCallback  objCallback 

'Load  a  Display  the  daps  with  labels 

Call  OpenUS_StatesLayer 

Call  OpenLISARC_GeoRef Layer 

Call  OpenStateCapitalsLayer 

Call  Openda jorCityLayer 

Call  DisplaydapLabels 

Call  Positiondap 

'Modify  the  dapinfo  Right-Click  denu 
Call  Initializedapinf odenu 
Call  Initial izedapInfoToolbar 
Call  Initializedapinf oStatusBar 

'Set  Zoom-In  tool  as  the  Default 
ob jGeoSelect • RundenuCommand  d_T00LS_EXPAND 
AriesStatusBar . Panels (S )- Text  =  "dapinfo  Tool  :  Zoom-In" 

Refresh 
End  Sub 

Private  Sub  Ini tdeasuresGrid (ByVal  Index  As  Byte) 
cProcName  =  "INITJEASURES^GRID" 

Dim  i  As  Integer 

Dim  iGridColumnWidth(condaximumColumns)  As  Integer 
Dim  cGridRowLabel (conTotaldeasures )  As  String 

'Load  Column  Width  array 
iGridColumnWidth (0)  =  conOneColumnWidth 
iGridColumnWidth(l)  =  conTwoColumnWidth 
iGridColumnWidth(B)  =  conThreeColumnWidth 
iGridColumnWidth (3 )  =  conFourColumnWidth 
iGr idCo lumnWidth ( M )  =  conFi veColumnWidth 


'Load  Row  Labels 
cGridRowLabel ( D) 
cGridRowLabel (1) 
cGridRowLabel (5) 
cGridRowLabel (3) 
cGridRowLabel ( M ) 
cGridRowLabel (S) 
cGridRowLabel (b) 
cGridRowLabel ( 7 ) 
cGridRowLabel ( fi ) 
cGridRowLabel ( T) 
cGridRowLabel (ID ) 
cGridRowLabel (11) 


array 

=  condeasureD 
=  condeasurel 
=  condeasureB 
=  condeasure3 
=  condeasureM 
=  condeasureS 
=  condeasureb 
=  condeasure? 

=  condeasureB 
=  condeasurel 
=  condeasurelD 
=  condeasurell 
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cGridRowLabel ( 12)  =  conneasurel2 
cGridRowLabel (13)  =  conMeasurelB 
cGridRowLabel ( m )  =  condeasurem 
cGridRowLabel  (IS)  =  confleasurelS 
cGridRowLabGl ( ID  =  condeasurelL 
cGridRowLabel  ( 17)  =  confleasurel? 
cGridRowLabe  1  ( Ifi )  =  confleasurelfi 
CGridRowLabel  (IT)  =  confleasurelT 
cGridRowLabel ( 2D )  =  condeasureBD 

Uith  griddeasures 

'Establish  Grid  default  parameters 
-Visible  =  True 
-Font-Size  =6 

'Reset  Grid  if  data  present 
-Cols  =  1 
-Cols  =  2 
-FixedCols  =  1 
-FixedRows  =  1 

'Set  rows  and  columns- 

-Rows  =  21 

-Cols  =  Index  +  2 

'Set  Fixed  Column  Label  size 
.ColUidth(D)  =  1370 

'Set  remaining  columns  width  dependent  on  number  of  Facilities 
For  i  =  1  To  Index  +  1 

.ColUidth(i)  =  iGridColumnWidthdndex) 

- ColAlignment ( i )  =  1 
Next  i 

'Display  Grid  Row  Labels  in  Column  1 
griddeasures - Col  =  0 
For  i  =  □  To  20 

griddeasures - Row  =  i 

griddeasures • Text  =  cGridRowLabel ( i ) 

Next  i 
End  With 
End  Sub 

Private  Sub  Ini tFaci 1 i tyinf oPanel  ( ) 

cProcName  =  "INIT_FACILITY_INFO_PANEL'’ 

iPropFacIDctr  =  0 

pnlFaci 1 i tyinf o - Enabled  =  False 
txtPropFacID - Visible  =  False 
cboUIC-Visible  =  False 
spinFacIDbtn - Visible  =  False 
Refresh 
End  Sub 

Private  Sub  InitFaci lityElements ( ) 

cProcName  =  "INIT^FACILITY^ELEdENTS” 

Dim  i  As  Byte 

cdovUic-UIC  =  "" 
cdovUic - FacID  =  "" 

tabAriesdap- Tab  =  D 
tabAriesUI-Tab  =  0 

fradovUIC-Tag  =  ”N0T  USED^ 
f  radovUIC-.Font -Size  =  ID 
txtdovUIC-Text  = 
txtdovUIC • Enabled  =  True 


'Loop  Variable 

'Set  dOVUIC  variable  to  NULL 


'Display  GeoSelection  dap 
'Display  Facility  Select  Tab 

'Initialize  Facility  Frame  TAGs 
'Set  Font  Size  to  default 
'Clear  dOVUIC  text  box 
'Allow  user  input 
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IstbxnovUIC.Clear 


Empty  listbox 


For  i  =  □  To  3  'Loop  thru  Facility  Frames 

f raFacilityCi )■ Enabled  =  False  'Disable  Frame 
fraFacility(i) ‘Font. Size  =  T  'Set  Font  Size  to  default 

txtFacID ( i )  •  Text  =  'Clear  facility  text  box 

txtFacID ( i ). Visible  =  False  'Hide  facility  text  box 

IstbxFacID ( i )• Clear  'Empty  facility  list  box 

IstbxFacID ( i )• Visible  =  False  'Hide  facility  list  box 
txtFacID(i) .Tag  =  "NOT  USED"  'Set  Frame  TAG  to  default 

Next  i 

For  i  =  0  To  M 

fraStatus ( i ). Enabled  =  False 
fraStatus ( i  ). Font  -  Size  =  ID 
txtStatus ( i ) -Text  =  "" 
txtStatus ( i )- Visible  =  True 
txtStatus ( i )- Enabled  =  True 
IstbxStatus ( i ) -Clear 
IstbxStatus  ( i )- Visible  =  False 
aFacID(i)  =  "" 

Next  i 

txtPropFacID -  Clear 
cboUIC-Clear 
IstbxUnitName- Clear 
txtCity-Text  =  "" 
txtState - Text  =  "" 
txtZipCode - Text  =  "" 

fraStatus (MeasuresFrameIndex )- Enabled  =  True 

barSCLstatus - Value  =  0  'Set  progress  bar  to  Zero 

iProgressIndicator  =  D  'Set  progress  indicator  default 

barS(3Lstatus  -  Min  =  0  'Set  Progress  bar  minimum 

Refresh 
End  Sub 

Private  Sub  InitGIStreeview( ) 

cProcName  =  "INIT_GIS_TREEVIEb)" 

trvGISData - Nodes  -  Clear 
trvGISData - Enabled  =  False 
Refresh 
End  Sub 

Private  Sub  InitAriesControls ( ) 

cProcName  =  "INIT^ARIES^CONTROLS" 

cmdAriesBtn - Enabled  =  False 
cmdClearBtn - Enabled  =  False 
cmdAcceptBtn - Visible  =  True 
cmdAcceptBtn - Enabled  =  False 
cmdAcceptBtn - Enabled  =  True 
cmdAcceptBtn - Font  -  Size  =  IB 
Refresh 
End  Sub 

Private  Sub . InitStatusBar () 

cProcName  =  "INIT_STATUS_BAR" 

AriesStatusBar - Panels (B) -  Text  = 

AriesStatusBar -Panels (3) -Text  = 

Refresh 
End  Sub 

Private  Sub  FormElementsLock (ByVal  iFacIndex  As  Byte) 
cProcName  =  "F0Rf1_ELEnENTS_L0CK" 

Dim  i  As  Byte  'Loop  Variable 

'Disable  fluery  and  Clear  user  entry  buttons 


'Disable  Measures  Button 
'Disable  CLEAR  button 

'Disable  ACCEPT  Button 


'Loop  thru  S(3L  status  frames 
'Disable  status  frame 
'Set  frame  font  default 
'Clear  status  text  box 
'Hide  status  text  box 

'Empty  status  listbox 
'Hide  status  list  box 


Call  Traf f icLight ( vbBlack) 
cmdClearBtn . Enabled  =  False 
cmdAcceptBtn . Enabled  =  False 

txtflovUIC  ■  Enabled  =  False 
IstbxflovUIC.  Enabled  =  False 

'Locks  User  input  until  (3uery  finished 
For  i  =  0  To  3 

txtFacID ( i )■ Enabled  =  False 
IstbxFacID ( i )• Enabled  =  False 
Next  i 

'Hides  Exposed  Facility  Frame  w/out  User  Input 
'If  Not  (iFacIndex  =  M)  Then 
'  txtFacID ( iFacIndex) . Visible  =  False 
'  IstbxFacID ( iFacIndex ). Visible  =  False 
'  fraFacility(iFacIndex) -Enabled  =  False 
'End  If 

'Bring  Aries  Measures  Computation  Tab  to  the  Front 
tabAriesUI - Tab  =  1 
Refresh 
End  Sub 

Private  Sub  Ini t ial izeProgressBar (ByVal  IFacIndex  As  Byte) 
cProcName  =  ”PROGRESS_BAR_INITIALIZE" 

Dim  iProgressIndicator  As  Integer 

'Initialize  Progress  Bar 

iStatusBarflax  =  ((iFacIndex  +  1)  *  conTotalMeasures )  +  _ 

((iFacIndex  +  1)  *  conTotalInterimTables )  +  conSingleMessages 

iProgressIndicator  =  □ 
lilith  barSCLstatus 
-Min  =  □ 

-Value  =  0 

-Max  =  iStatusBarMax 
End  Uith 
Ref  resh 
End  Sub 

Private  Sub  Display(2ueryStartTime  (ByVal  cStartTime  As  String) 
cProcName  =  ”DISPLAY_(3UERY_START_TIME” 

lilith  AriesStatusBar 

-  Panels ( 1 )- Text  =  LaunchMapinf oMSG 
c(2ueryStartTime  =  cStartTime 

-  Panels (B) -  Text  =  "Start  "  &  cflueryStartTime 
End  With 

Refresh 
End  Sub 

Private  Sub  Disp layflueryEndTime  (By Val  c(2ueryEndTime  As  String) 
cProcName  =  "DISPLAY_t3UERY_END_TinE" 

'Display  (2uery  End  Time 
With  AriesStatusBar 

-  Panels  (E)  -  Text  =  "End  "  &  ciSueryEndTime 
Call  ElapsedTimer ( c(2ueryEndTime ) 

End  With 
Refresh 
End  Sub 

Private  Sub  CompareFacilities ( ) 

cProcName  =  "C0I1PARE_FACILITIES" 

Dim  i  As  Byte 
Dim  j  As  Byte 
Dim  iFacIDctr  As  Byte 
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'Loop  Variable 
'Loop  Variable 


Dim  iConf irmResponsG  As  Integer 
Dim  cAriesConf irmHessage  As  String 
Dim  bDuplicateFacility  As  Boolean 
Dim  bSingleFaci 1 ity  As  Boolean 
Dim  aMeasures(M)  As  Measures^Type 
Dim  rsFacilities  As  Recordset 

Set  rsFacilities  =  dbAcropolis - OpenTable ("VALID_UNIT"n  dbOpenTable) 

bDuplicateFacility  =  False 
bSingleFacility  =  False 

cAriesConf irmtlessage  =  AriesConf irmllSG  S  vbCr 
cMovUic-UIC  =  ” 

'Function  determines  the  Total  number  of  Facilities  Proposed 
iFacIDctr  =  IDD 

'Determine  if  Proposed  Facilities  meet  criterium  (2  minimum) 

'If  iFacIDctr  =  D  Then 
'  bSingleFacility  =  True 
'  Call  InitFacilityElements 
'  txtnovUIC . Text  =  cMovUic-UIC 

'Else  'Check  if  Duplicate  Facility  Selected 

'  For  i  =  □  To  (iFacIDctr  ~  1) 

'  For  j  =  (i  +  1)  To  iFacIDctr 

'  If  aFacIDCi)  =  aFacID(j)  Then  bDuplicateFacility  =  True 

'  Next  j 

'  Next  i 
'End  If 

'Build  Confirmation  message 
'For  i  =  0  To  iFacIDctr 

'  cAriesConf irmhessage  =  cAriesConf irmtlessage  &  SpaceCM)  8;  aFacID(i)  &  ” 

'Next  i 

'  cAriesConf  irmtlessage  =  Left$  ( cAriesConf  irmtlessage  n 
(Len  ( cAriesConf  irmtlessage )  -  1)) 

cAriesConf irmtlessage  =  "This  will  conduct  a  calculation  of  the  Valid 
Facilities  in  the  Valid  Unit  List" 

'If  bDuplicateFacility  Then  'Duplicate  facility  exists 

'  Call  Displaytlessage (DuplicateFacilitytlSGi  vbCriticali  vbOKOnlyi 
conFaci li tyEr r or Caption) 

'Elself  bSingleFacility  Then  'Single  facility  exists 

'  Call  Displaytlessage (InvalidGIS(3uGryt1SGi  vbCriticali  vbOKOnlyi 
conFaci 1 it yError Caption) 

'End  If 

If  Not  bDuplicateFacility  And  Not  bSingleFacility  Then 
Screen -MousePointer  =  vbHourglass 

iConf  irmResponse  =  tIsgBox  ( cAriesConf  irmtlessage  n  vb(3uestion  +  vbOKCancel 
"Launch  ARIES  v3.D") 

If  iConf irmResponse  =  vbOK  Then 

Call  FormElementsLock ( iFacIDctr) 

Call  D i splay flueryS tar tT ime (Time$ ( ) ) 

Call  InitializeProgressBarC iFacIDctr) 

'Call  CreateI10S_InterestTable  (cdovUic .  UIC) 

Uith  rsFacilities 
-  tloveFirst 

'Loop  thru  all  proposed  facilities 
For  i  =  □  To  iFacIDctr 

atleasuresCi) -FacID  =  -Fields ("FAC_ID") -Value  'aFacID(i) 

Call  GetArchivedFacility  (afleasures  ( i  )  T  cllovUic  -  UIC) 


If  Not  aheasures ( i )■ Archived  Then 


Call  NonGISfluery (aneasures ( i ) ) 

'  End  If 

Call  GlSCuery  (alleasures(i) ) 

Call  ResetSfiLf names 

Call  Arch iveFacility Measures (aMeasures (i ) ) 

- MoveNext 
Next  i 
End  With 

Call  CloseGISfluery 

Call  DeleteTempAccessTables 

Call  Display(3ueryEndTime(Time^()) 

'  Call  OutputComputedMeasures (aMeasures () T  iFacIDctr) 

tbararies - Buttons ("import”) -  Enabled  =  True 
cmdClearBtn .Enabled  =  True 
bSflLfiueryDone  =  True 
End  If 
End  If 

Screen - MousePointer  =  vbDefault 
End  Sub 

Private  Sub  GetArchivedFacility (ByRef  aMeasures  As  Measures^Typei  ByVal 
cMovUic  As  String) 

cProcName  =  "Get_Archived_Facility” 

Dim  rsArchivedFacili ty  As  Recordset 
Dim  (3defnS(3L  As  String 

(3defnS(2L  =  "Select  *  From  Repository  Where  FAC_ID  =  '"  8  aMeasures  -  FacID  8 
Order  by  MOVUIC" 

AriesStatusBar.Panels(l) .Text  =  Archi vedFacilityMSG 
Refresh 

'Open  Facility  Respository  Database 

Set  rsArchivedFacility  =  dbTel iko - OpenRecordset ((2def nSCL t  dbOpenSnapshotn 
dbReadOnly ) 

With  rsArchivedFacility 

If  TableNotNULL (rsArchivedFacility )  Then 
- MoveFirst 

AriesStatusBar . Panels (1) . Text  =  LoadingArchi veMSG  &  !Fac_ID 
Refresh 

'Transfer  Facility  Record  to  Measures  table 
aMeasures . Archived  =  True 

Call  DisplayStatus (conMeasureli  NonGISFrameIndex ) 
aMeasures . FacBack logdMaint  =  !FAC_MAINT  'Measure  #1 

Call  DisplayStatus (conMeasureSi  NonGISFrameIndex) 
aMeasures - OperatingCost  =  !FAC_0PC0ST  'Measure  #S 

Call  DisplayStatus (conMeasureB 1  NonGISFrameIndex) 
aMeasures . Fac Age  =  !FAC_AGE  'Measure  #3 

Call  DisplayStatus (conMeasureM i  NonGISFrameIndex) 
aMeasures • FacCond  =  !FAC_C0ND  'Measure 

Call  DisplayStatus(conMeasure5n  NonGISFrameIndex) 
aMeasures  .  FacOwned  =  !FAC_OlilNED  'Measure  #5 

Call  DisplayStatus(conMeasurebT  MeasuresFrameIndex ) 
aMeasures  .  Competition  =  ICOMPETION  'Measure 

Call  DisplayStatus (conMeasure?-!  MeasuresFrameIndex) 
aMeasures . AreaDri 1 1 Attend  =  !DRILL_ATND  'Measure  ^7 

Call  DisplayStatus (conMeasurefli  MeasuresFrameIndex) 
aMeasures - AreaLossRate  =  !AREA_L0SS  'Measure  #5 

Call  DisplayStatus (conMeasureT T  MeasuresFrameIndex) 
aMeasures - AreaXferRate  =  !AREA__XFER  'Measure 

Call  DisplayStatus (conMeasurelQi  MeasuresFrameIndex) 
aMeasures - A vgAreaMan  =  !AVG_MANING  'Measure  #10 

Call  DisplayStatus ("RZA  Distance"!  GISNonSflLFrameIndex ) 
aMeasures . DistToRecruit  =  !DIST_RZA  'Measure  #11 

Call  DisplayStatus (conMeasurelEi  MeasuresFrameIndex) 
aMeasures . Total Aval IClos  =  !AVAIL_CLOS  'Measure  #1B 

Call  DisplayStatus (conMeasurel3!  MeasuresFrameIndex) 
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afleasures  . IRR  =  !IRR  'Measure  #13 

Call  DisplayStatus (conMeasurelM n  MeasuresFrameIndex ) 
afleasures  .  RecruitMarket  =  !REC_HARKET  'Measure  #m 

Call  DisplayStatus (conMeasurelSi  MeasuresFrameIndex) 
aMeasures . Reassignments  =  IREASSI6N  'Measure  #15 

Call  DisplayStatus ("AMSA  Distance"!  GISNonS(2LFrameIndex ) 
aMeasures  •  DistToAMSA  =  !DIST_AMSA  'Measure  #lt 

Call  DisplayStatus ("ECS  Distance"!  GISNonS(3LFrameIndex) 
aMeasures  . DistToECS  =  !DIST_ECS  'Measure  #17 

Call  DisplayStatus  ( CO nNoAuthNG!  GISNonStJLFrameIndex ) 

Call  DisplayStatus (vbNullString 1  GISNonSflLFrameIndex ) 

Call  DisplayStatus (conMeasurelfl!  NonGISFrameIndex ) 

Call  DisplayStatus (vbNul IString!  NonGISFrameIndex ) 
aMeasures . FacWkndUsed  =  !liIKND_USED  'Measure  #lfl 

Call  IncrementProgressBar 
Call  IncrementProgressBar 

.FindFirst  "MOVUIC  =  '"  &  cMovUic  a  "'" 

If  Not  -NoMatch  Then 

aMeasures  .  MovUICJatch  =  True 

Call  DisplayStatus  ( conMeasuren!  MeasuresFrameIndex) 
aMeasures . MOSAvailClos  =  !M0S_AVAIL  'Measure  #n 

Call  DisplayStatus ( conMeasureED!  MeasuresFrameIndex) 
aMeasures. IRR_M0S  =  !IRR_M0S  'Measure  #E0 

'Increment  Progress  Bar  to  account  for  No  Temp  Tables  created 
iStatusBarMax  =  iStatusBarMax  -  IE 
barS(3Lstatus  .  Max  =  iStatusBarMax 
Else 

aMeasures . MovUIC_Match  =  False 
End  If 
End  If 
•Close 
End  With 

Set  rsArchivedFacility  =  Nothing 

End  Sub 

Private  Sub  CreateMOS_InterestTable (ByVal  cMovUic  As  String) 
cProcName  =  "CREATE_MOS_INTEREST_TABLE" 

Dim  c(2defnSi3L  As  String 

Dim  bNoASSNxMOS_Exists  As  Boolean 

AriesStatusBar . Panels (1) -  Text  =  BuildMOSInterestMSG 

bNoASSNxMOS^Exists  =  CreateNoASSNxMOStable (cMovUic) 

If  bNoASSNxMOS_Exists  Then 

'Create  Interim  Table  C  MOS_INTEREST  1 

Call  DisplayStatus  (TblJOSInterest!  SflLFrameIndex ) 

c(2defnS(3L  =  GetMOSInterestfiuery 

Call  BuildAccessTable (Tbl_MOSInterest 1  Gdef_MOSInterest !  cfldefnSlSL) 

End  If 

End  Sub 

Private  Function  CreateNoASSNxMOStable (ByVal  cMovUic  As  String)  As  Boolean 
Dim  c(2defnS(2L  As  String 

'Create  Interim  Table  C  NoASSNxMOS  1 

cfldefnS(3L  =  NoASSNxM0S(3ueryBegin  &  cMovUic  &  NoASSNxMOStfueryEnd 
Call  DisplayStatus ( Tbl_NoASSNxMOS !  SflLFrameIndex ) 

Call  BuildAccessTableCTbl^NoASSNxMOSi  (3def_NoASSNxM0S !  cfldefnStJL) 
CreateNoASSNxMOStable  =  True 

End  Function 

Private  Function  GetMOSInterestfluery ( )  As  String 
cProcName  =  "GET_M0S_INTEREST_r3UERY" 

Dim  rsMOS_Total  As  Recordset 
Dim  rsM0S_Top3  As  Recordset 

Dim  iRecordCtr  As  Long 
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Dim  inOS_Total  As  Integer 
Dim  inOS_Top3  As  Integer 
Dim  nOSPercent  As  Single 

nOSPercent  =  O-S 
inOS^Total  =  D 
inOS_Top3  =  0 

On  Error  GoTo  EH_f10Sinterest 

'Execute  S(2L  ^2uery  for  f10S_Count  Summation 

Set  rsriOS_Total  =  dbAcropolis  -  OpenRecordset  (nOS__Total(3ueryT  dbOpenDynaset i 
dbReadOnly ) 

If  fluerySumNotNULL(rsf10S_Total  !n0S_T0TAL)  Then 
inOS_Total  =  rsMOS^Total inOS^TOTAL 
Else 

inoS^Total  =  -1 


'Execute  S(2L  fluery  for  MOS^Top  3 

Set  rsf10S_Top3  =  dbAcropolis  .  OpenRecordset  (n0S_Top3(2uery t  dbOpenDynaset n 
dbReadOnly) 

'Sum  Top  3  noS's 
Uith  rsnOS_Top3 

If  TableNotNULL(rsnOS_Top3)  Then  -hoveLast 
iRecordCtr  =  .RecordCount 

If  TableNotNULL  (rsnOS_To*p3)  And  iRecordCtr  =  3  Then 
.  floveFirst 

inOS_Top3  =  !nOS_COUNT 
. HoveNext 

il10S_Top3  =  il10S_Top3  +  !r!0S__C0UNT 
.  rioveLast 

inOS_Top3  =  inOS_Top3  +  !nOS_COUNT 
Else 

inOS_Top3  =  1 
End  If 
End  Uith 

'Determine  H0S  of  Interest 

If  (CSng(iriOS_Top3)  /  CSng ( inOS_Total) )  >  dOSPercent  Then 
GetnOSInterest(3uery  =  dOS_INT_Top3(3uery 
Else 

Getn0SInterest(3uery  =  nOS_INT_Total(3uery 
End  If 

'Delete  Recordset  Objects 
rsdOS^Total .Close 
rsriOS_Top3  .Close 
Set  rsdOS^Total  =  Nothing 
Set  rsnOS_Top3  =  Nothing 

Exit  Function 

EHJOSinterest : 

Select  Case  Err-Number 

Case  ERR_Inval idUseOFNul 1 
inOS_Total  =  -1 
Resume  Next 

Case  Else  'Trap  all  other  Errors  &  Report 
Call  OutputERROR^LOG 
End 


End  Select 
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End  Function 


Private  Sub  ResetS(2Lf  names  ( ) 

IstbxStatus (Measures Frame Index ) -  Clear 
txtStatus (MeasuresFrameIndex ) -Text  =  ”” 

IstbxStatus(NonGISFramelndex)- Clear 
txtStatus ( NonGISFrameIndex ) -  Text  =  "" 

lstbxStatus(GISNonS(2LFrameIndex).Clear 
txtStatus  (GISNonS(2LFrameIndex)  .Text  =  ”” 

IstbxStatus  (S(2LFrameIndex ).  Clear 
txtStatus  (St3LFrameIndex)  .  Text  =  ”” 

End  Sub 

Private  Sub  NonGISc2uery (ByRef  aMeasures  As  Measures_Type ) 
cProcName  =  ”N0N_GIS_(2UERY" 

Dim  rsFacBklogdMaintMeasure  As  Recordset  'Measure  #1 
Dim  rsOpCostFacCondMeasure  As  Recordset  'Measure 

Dim  rsFacAgeMeasure  As  Recordset  'Measure  #3 

Dim  rsFacOwnedUsedMeasure  As  Recordset  'Measure  #5  &  #lfl 

Set  rsFacBklogdMaintMeasure  =  dbAcropolis -OpenRecordset (Tbl_RPINFODTn 
dbOpenTable 1  dbReadOnly) 
rsFacBklogdMaintMeasure - Index  =  ”FACID” 

Set  rsOpCostFacCondMeasure  =  dbAcropolis . OpenRecordset (Tbl^FPSi  dbOpenTablei 
dbReadOnly) 

rsOpCostFacCondMeasure . Index  =  ”FACID” 

Set  rsFacAgeMeasure  =  dbAcropol is - OpenRecordset ( Tbl_Interest n  dbOpenTablei 
dbReadOnly) 

rsFacAgeMeasure . Index  =  ”FACID” 

Set  rsFacOwnedUsedMeasure  =  dbAcropolis.OpenRecordset(Tbl_ComplexT 
dbOpenTablei  dbReadOnly) 
rsFacOwnedUsedMeasure -Index  =  ”FACID” 

'Calc  Measure  #1 
With  rsFacBklogdMaintMeasure 
■Seek  aMeasures . FacID 

If  Not  (.NoMatch)  Then 

aMeasures . FacBacklogdMaint  =  !Maint_Cost 
Else 

aMeasures . FacBacklogdMaint  =  Def aul tErrorValue 
End  If 

Call  DisplayStatus (conMeasureln  NonGISFrameIndex ) 

End  With 

'Calc  Measure  #E  & 

rsOpCostFacCondMeasure . Seek  aMeasures - FacID 

If  Not  (rsOpCostFacCondMeasure . NoMatch)  Then 

aMeasures . OperatingCost  =  rsOpCostFacCondMeasure ! C0ST_PR_SF 

'Verify  that  the  stored  value  is  not  NULL 
If  Not  IsNull (rsOpCostFacCondMeasure !FAC_C0ND)  Then 
aMeasures - FacCond  =  rsOpCostFacCondMeasure ! FAC_C0ND 
Else 

aMeasures . FacCond  =  Def aul tErrorValue 
End  If 
Else 

aMeasures ■ OperatingCost  =  Def aultErrorValue 
aMeasures .FacCond  =  Def aultErrorValue 
End  If 

Call  DisplayStatus (conMeasureBn  NonGISFrameIndex) 

Call  DisplayStatus  (conMeasurei* T  NonGISFrameIndex) 
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'Calc  Measure  #3 
With  rsFacAgeMeasure 

-Seek  aMeasures . FacID 

If  Not  (-NoMatch)  Then 

If  Not  IsNulKIDATE^ACfi)  Then 

aMeasures  -  FacAge  =  ComputeFaci  lityAge  ( !  DATE_AC(3 ) 

Else 

aMeasures • FacAge  =  Bef aultErrorValue 
End  If 
Else 

aMeasures ■ FacAge  =  Bef aultErrorValue 
End  If 

Call  BisplayStatus  (conMeasure3-i  NonGISFrameIndex ) 

End  With 

'Calc  Measure  #5  &  #  Ifl 

rsFacOwnedUsedMeasure-Seek  aMeasures •  FacIB 

If  Not  (rsFacOwnedUsedMeasure-NoMatch)  Then 

If  Not  IsNull (rsFacOwnedUsedMeasure ! FAC_0WNEB )  Then 

aMeasures - FacOwned  =  rsFacOwnedUsedMeasure ! FAC_0WNEB 
Else 

aMeasures - FacOwned  =  Bef aultErrorValue 
End  If 

aMeasures  -  FacWkndUsed  =  rsFacOwnedUsedMeasure  !  FACJKNBJSEB 
Else 

aMeasures - FacOwned  =  Bef aultErrorValue 
aMeasures • FacWkndUsed  =  Bef aultErrorValue 
End  If 

Call  BisplayStatus (conMeasureSi  NonGISFrameIndex ) 

Call  BisplayStatus (conMeasurelfii  NonGISFrameIndex) 

Call  BisplayStatus (vbNullStringi  NonGISFrameIndex) 

'Close  Recordset  Objects 

Set  rsFacBklogdMaintMeasure  =  Nothing 
Set  rsOpCostFacCondMeasure  =  Nothing 
Set  rsFacAgeMeasure  =  Nothing 
Set  rsFacOwnedUsedMeasure  =  Nothing 
End  Sub 

Private  Sub  GISfiuery (ByRef  aMeasures  As  Measures_Type ) 
cProcName  =  "GIS_(2UERY” 

Bim  cfldefnSrSL  As  String 
Bim  rsArchive  As  Recordset 
Bim  rsNoREiSB  As  Recordset 
Bim  rsNoAuthNG  As  Recordset 
Bim  rsNoASSN  As  Recordset 
Bim  rsNoLOSS  As  Recordset 
Bim  rsNoXFER  As  Recordset 
Bim  rsBrillTotal  As  Recordset 
Bim  rsBrillSAT  As  Recordset 
Bim  rsAvailClos  As  Recordset 
Bim  rsIRR  As  Recordset 
Bim  rsRecruitMarket  As  Recordset 
Bim  rsReassignments  As  Recordset 
Bim  rsMOSA vai IClos  As  Recordset 
Bim  rsIRR__M0S  As  Recordset 

'Bisplay  Statusbar  message 

AriesStatusBar • Pane  Is ( 1 )- Text  =  SfiLStatusMSG  S  aMeasures - FacIB 

'  If  Not  aMeasures - Archived  Then 

'Execute  Mapinfo  Geo(3uery  via  OLE  interface 

Call  BisplayStatus (aMeasures • FacIB T  Mapinf oFrameIndex ) 

If  bMapiSueryActi ve  Then 

Call  Mapinf o flue ry ( aMeasures • FacIB ) 

Else 

Call  BisplayMessage  ( OLEf ailedMSGi  vbCriticaln  vbOKOnly-t  _ 
conOLEcaption) 
bMapBasicRunning  =  False 
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Call  cmdExitBtn_Click 
End  If 

Call  ElapsedTimerdime^  () ) 

'Get  calculated  AMSAi  ECSn  &  RZA  Distances  from  proposed  Facility 
Call  GetFacilityDistances (aHeasures)  'Measure  Itn  17 

'Build  Temp  Tables  FinanceCYi  AreaFacID-i  AreaZipCoden  AreaUICn  AreaClosUIC 

Call  CreateFinanceTempTable 

Call  CreateAreaFacIDTempTable 

Call  CreateArealllCTempTable 

Call  CreateAreaClosUICTempTable 

Call  CreateAreaZipCodeTempTable 

Call  CreateAreaGlflZipTempTable 

Call  CreateAreaGlfiMOSTempTable 

Call  DisplayStatusCvbNullStringi  StJLFrameIndex ) 

'Calculate  Measure  #ti 

Call  DisplayStatus (conMeasuretn  MeasuresFrameIndex ) 

Set  rsNoAuthNG  =  dbAcropolis • OpenRecordset (ExTbl_AreaDistance i 
dbOpenSnapshot T  dbReadOnly) 
rsNoAuthNG . MoveFirst 

Call  DisplayStatus  (conNoAuthNGn  GISNonS(2LFrameIndex ) 

Call  DisplayStatus  (vbNullStringi  GISNonS(3LFrameIndex ) 

Set  rsNoRE(3D  =  dbAcropol is - OpenRecordset ( NoReqdfluery t  dbOpenSnapshot t 
dbReadOnly) 

If  fluerySumNotNULL  ( rsNoREt2D  !  T0TAL_RE(2D )  Then 

aMeasures • Competition  =  rsNoAuthNG ! N0_AUTH_NG  +  rsNoRE(3D ! TOTAL_REflD 
Else 

aMeasures • Competition  =  Def aultErrorValue 
End  If 

'Calculate  Measure  #7 

Call  DisplayStatus (conMeasure7T  MeasuresFrameIndex) 

Set  rsDrillTotal  =  dbAcropo 1 i s . OpenRecordset ( Dri 1 ITotalfluery i 
dbOpenSnapshot -1  dbReadOnly) 

Call  ElapsedTimer (Time^ ( ) ) 

Set  rsDrillSAT  =  dbAcropolis - OpenRecordset (DrillSATfluery i  dbOpenSnapshot n 
dbReadOnly) 

If  (2uerySumNotNULL  (rsDri llTotal ! DRILL_TOTAL )  And 
(2uerySumNotNULL(  rsDrillSAT  I  TOTALIS  AT)  Then 
If  rsDrillTotal !DRILL_TOTAL  Then 

aMeasures - AreaDrillAttend  =  rsDril ISAT ! T0TAL_SAT  / 
rsDrillTotal !DRILL_TOTAL 
Else 

aMeasures - AreaDrillAttend  =  Def aultErrorValue 
End  If 
Else 

aMeasures - AreaDrillAttend  =  Def aultErrorValue 
End  If 

'Calculate  Measure 

Call  DisplayStatus (conMeasurefli  MeasuresFrameIndex) 

Set  rsNoASSN  =  dbAcropolis  -  OpenRecordset  ( NoASSN(2uery  ■»  dbOpenSnapshot t 
dbReadOnly) 

Call  ElapsedTimer ( Time$ ( ) ) 

Set  rsNoLOSS  =  dbAcropol is  •  OpenRecordset  ( NoLOSSfluery  i  dbOpenSnapshot -i 
dbReadOnly) 

If  (3uerySumNotNULL(rsNoASSN!T0TAL_ASSN)  Then 

If  (3uerySumNotNULL(rsNoL0SS!T0TAL_L0SS)  And  rsNoASSN ! TOTAL^ASSN  Then 
aMeasures - AreaLossRate  =  rsNoLOSS ! T0TAL_L0SS  /  rsNoASSN !TOTAL_ASSN 
Else 

aMeasures • AreaLossRate  =  D 
End  If 
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Else 

afleasures  -  AreaLossRate  =  Def  aul  tErrorValue 
End  If 

'Calculate  fleasure 

Call  DisplayStatus  (confleasureTi  MeasuresFramelndex  ) 

Set  rsNoXFER  =  dbAcropolis . OpenRecordset (NoXFER(2uery i  dbOpenSnapshot i 
dbReadOnly ) 

If  fluerySuinNotNULL(rsNoASSN!TOTAL_ASSN)  Then 

If  (3uerySumNotNULL(rsNoXFER!T0TAL„XFER)  And  rsNoASSN ! TOTAL^ASSN  Then 
aMeasures-AreaXferRate  =  rsNoXFER ! TOTAL_XFER  /  rsNoASSN ! TOTAL_ASSN 
Else 

afleasures  -  AreaXf  erRate  =  D 
End  If 
Else 

aHeasures - AreaXf erRate  =  Def aultErrorValue 
End  If 

'Calculate  Measure  #1D 

Call  DisplayStatus (conMeasurelDi  MeasuresFramelndex) 

If  (3uerySumNotNULL(rsNoASSN!T0TAL_ASSN)  And 
(2uerySumNotNULL(rsNoRE(2D!TOTAL_RE(2D)  Then 

aMeasures - AvgAreaMan  =  rsNoASSN ! TOTAL_ASSN  /  rsNoREflD ! T0TAL_RE(2D 
Else 

aMeasures - A vgAreaMan  =  D 
End  If 

'Calculate  Measure  #12 

Call  DisplayStatus ( conMeasurelEi  MeasuresFramelndex) 

Set  rsAvailClos  =  dbAcropolis . OpenRecordset (TotalAvailClos(3ueryn 
dbOpenSnapshot T  dbReadOnly) 

If  (3uerySumNotNULL(rsAvailClos!T0TAL_AVAIL)  Then 

aMeasures - TotalAvailClos  =  rsAvailClos ! TOTAL_AVAIL 
Else 

aMeasures . TotalAvailClos  =  Def aultErrorValue 
End  If 

'Calculate  Measure  #13 

Call  DisplayStatus ( conMeasurelBi  MeasuresFramelndex) 

Set  rsIRR  =  dbAcropol is • OpenRecordset (TotalIRRfluery t  dbOpenSnapshot t 
dbReadOnly) 

If  fiueryCountNotNULL(rsIRR!TOTAL_IRR)  Then 
aMeasures • IRR  =  rsIRR ! T0TAL_IRR 
Else 

aMeasures - IRR  =  Def aultErrorValue 
End  If 

'Calculate  Measure  #m 

Call  DisplayStatus (conMeasurelMn  MeasuresFramelndex) 

Set  rsRecruitMarket  =  dbAcropolis  -  OpenRecordset  ( RecruitMarketr2uery-i 
dbOpenSnapshot 1  dbReadOnly) 

If  (SuerySumNotNULL ( rsRecruitMarket ! TOTAL_MARKET)  Then 

aMeasures -RecruitMarket  =  rsRecruitMarket ! TOTAL_MARKET 
Else 

aMeasures . RecruitMarket  =  Def aultErrorValue 
End  If 

'Calculate  Measure  #15 

Call  DisplayStatus (conMeasurelSn  MeasuresFramelndex) 
ciSdefnSfiL  =  Reassign(3ueryBegin  &  cMovUic-UIC  &  ReassigniSueryEnd 
Set  rsReassignments  =  dbAcropolis - OpenRecordset ( cfldef nSflLn 
dbOpenSnapshot n  dbReadOnly) 

If  (3uerySumNotNULL (rsReassignments ! TOTAL_RESERVISTS)  Then 

aMeasures . Reassignments  =  rsReassignments ! TOTAL_RESERVISTS 


Else 

afleasures .  Reassignments  =  Def  aul  tErrorValue 
End  If 

'Calculate  Measure 

Call  DisplayStatus (conMeasurelTi  HeasuresFrameIndex ) 

Set  rsMOSAvailClos  =  dbAcropol is - OpenRecordset (TotalClosM0S(2uery i 
dbOpenSnapshot 1  dbReadOnly) 

If  (3uerySumNotNULL(rsM0SAvailClos!T0TAL_CL0S_M0S)  Then 
aMeasures -MOSAvailClos  =  rsMOSAvailClos ! T0TAL„CL0S_M0S 
Else 

aMeasures .MOSAvailClos  =  Def aultErrorValue 
End  If 

'Calculate  Measure  #ED 

Call  OisplayStatus ( conMeasureEDi  MeasuresFrameIndex ) 

Set  rsIRR_M0S  =  dbAcropolis-0penRecordset(TotalIRR_M0Si3ueryT 
dbOpenSnapshot T  dbReadOnly) 

If  ^3ueryCountNotNULL  ( rsIRR_M0S  !  T0TAL_IRR_M0S )  Then 
aMeasures. IRRJOS  =  rsIRRJOS  !  TOTAL^IRR^MOS 
Else 

aMeasures . IRR_M0S  =  Oef aultErrorValue 
End  If 

Call  ElapsedTimer (Time$ ( ) ) 

Elself  Not  aMeasures . MovUIC_Match  Then 

'Execute  Mapinfo  Geo(3uery  via  OLE  interface 
Call  OisplayStatus (aMeasures -FacIOT  Mapinf oFratneIndex ) 

If  bMap(2ueryActive  Then 

Call  Mapinfofluery (aMeasures - FacIB) 

Else 

Call  OisplayMessage (OLEfailedMSGi  vbCriticali  vbOKOnlyi  conOLEcaption ) 
bMapBas icRunning  =  False 
Call  cmdExitBtn_Cl ick 
End  If 

Call  ElapsedTimer (Time^ () ) 

'Build  Temp  Tables  FinanceCYn  AreaFacIO-i  AreaZipCodei  AreaUICn  AreaClosUIC 
Call  CreateAreaFacIOTempTable 
Call  CreateAreaUICTempTable 
Call  CreateAreaClosUICTempTable 
Call  CreateAreaZipCodeTempTable 
Call  CreateAreaGlfiMOSTempTable 

Call  I>isplayStatus( vbNullStringi  SflLFrameIndex ) 
iStatusBarMax  =  iStatusBarMax  ~  M 
barS(2Lstatus  .Max  =  iStatusBarMax 

'Calculate  Measure 

Call  OisplayStatus  (conMeasuren-i  MeasuresFrameIndex) 

Set  rsMOSAvailClos  =  dbAcropol is . OpenRecordset (TotalClosM0S(3uery t 
dbOpenSnapshot T  dbReadOnly) 

If  (JuerySumNotNULL ( rsMOSAvai IClos ! T0TAL_CL0S_M0S )  Then 
aMeasures . MOSAvai IClos  =  rsMOSAvailClos  !  T0TAL_CL0S_M0S 
Else 

aMeasures . MOSAvai IClos  =  Oef aultErrorValue 
End  If 

'Calculate  Measure 

Call  OisplayStatus (conMeasureSDi  MeasuresFrameIndex) 

Set  rsIRR_M0S  =  dbAcropolis  .  0penRecordset(TotalIRR_M0S(2uery -i 
dbOpenSnapshot T  dbReadOnly) 

If  GueryCountNotNULL(rsIRR_MOS!TOTAL_IRR_MOS)  Then 
aMeasures . IRR_M0S  =  rsIRR_M0S 1 TOTAL_IRR_MOS 
Else 

aMeasures. IRR_n0S  =  Oef aultErrorValue 
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End  If 

Call  ElapsedTimer (Time^ () ) 

'  End  If 

'Delete  Recordset  Objects 
Set  rsNoAuthNG  =  Nothing 
Set  rsNoRE(2D  =  Nothing 
Set  rsNoASSN  =  Nothing 
Set  rsNoXFER  =  Nothing 
Set  rsNoLOSS  =  Nothing 
Set  rsDrillTotal  =  Nothing 
Set  rsDrillSAT  =  Nothing 
Set  rsAvailClos  =  Nothing 
Set  rsRecruitnarket  =  Nothing 
Set  rsReassignments  =  Nothing 
Set  rshOSAvailClos  =  Nothing 
Set  rsIRRJOS  =  Nothing 
Set  rsIRR  =  Nothing 
End  Sub 

Private  Sub  CloseGISfluery ( ) 

cProcName  =  '’CL0SE_GIS_(2UERY" 

ob  jGeofiuery  -  RunMenuCommand  n__FILE„EXIT 

Call  DisplayStatus  ( CompleteflSGi  fleasuresFramelndex ) 

Call  DisplayStatus  ( CompleteflSGT  NonGISFrameIndex ) 

Call  DisplayStatus ( vbNul IStr ing 1  Napinf oFrameIndex ) 

Call  DisplayStatus  < CompleteflSG  1  Mapinf  oFrameIndex ) 

Call  DisplayStatus ( CompleteHSGT  GISNonSflLFrameIndex ) 

Call  DisplayStatus ( CompletenSGi  SflLFrameIndex ) 

'  barS(2Lstatus  •  Value  =  iStatusBarflax 

End  Sub 

Private  Sub  GetFaci 1 i tyDistances ( ByRef  adeasures  As  Measures^Type ) 
cProcName  =  "GET_FACILITY_DISTANCES” 

Dim  rsFaci  1  i tyDistancefleasures  As  Recordset  'Measures  #17 

On  Error  GoTo  EH_FacDist 

'Open  External  Table 

Set  rsFacilityDistanceMeasures  = 

dbAcropolis - OpenRecordset (ExTbl_AreaDi stance i  dbOpenDynaset n  dbReadOnly) 

Call  DisplayStatus  ( ”AMSA  Distance"-!  GISNonS(3LFrameIndex ) 

Call  DisplayStatus  ("ECS  Distance"-!  GISNonSfiLFrameIndex ) 

Call  DisplayStatus ("RZA  Distance"-!  GISNonSfiLFrameIndex ) 

If  TableNotNULL (rsFacilityDistanceMeasures)  Then 
With  rsFacilityDistanceMeasures 
•MoveFirst 

'Input  Facility  Distances  into  Measure  Table 

aMeasures - DistToAMSA  =  !AMSA_DIST  'Measure 
aMeasures .  DistToECS  =  !ECS__DIST  'Measure  #17 

aMeasures - DistToRecruit  =  !RZA_DIST  'Measure  #11 
End  With 
Else 

aMeasures • DistToAMSA  =  Def aul tErrorValue 
aMeasures . DistToECS  =  Def aultErrorValue 
aMeasures • DistToRecruit  =  Def aultErrorValue 
End  If 

Call  DisplayStatus  (vbNullString -I  GISNonSfSLFramelndex ) 

'Delete  Recordset  Object 
rsFacilityDistanceMeasures -Close 
Set  rsFacilityDistanceMeasures  =  Nothing 
Exit  Sub 
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EH_FacDist:  'Error  Handler 

Select  Case  Err-Number 

Case  ERR_ExtrnTableNotAttached 

'call  AttachExternalTable  (ExTbl„Areal>istance ) 

Resume 

Case  Else  'Trap  all  other  Errors  &  Report 
Call  OutputERROR^LOG 
Resume  Next 
End  Select 
End  Sub 

Private  Sub  CreateFinanceTempTable ( ) 

cProcName  =  ”CREATE_FINANCE_TEI1P_TABLES” 

Dim  c(2defnS(3L  As  String 

Dim  dtDate  As  Date 

Dim  cCY_i3TR  As  String  *  1 

'Initialize  Date  parameters 
dtDate  =  Now 

cCY_(3TR  =  DatePart (”q”T  dtDate) 

Select  Case  CInt  ( cCY_(2TR ) 

Case  M 

c(3defnS(3L  =  (31FY_SCRN 
Case  li 

ct2defnSflL  (3SFY_SCRN 
Case  2 

c(2defnS(2L  =  fl3FY_SCRN 
Case  3 

cfldefnSflL  =  (3MFY_SCRN 
End  Select 

'Create  Interim  Table  C  FINANCE_CY  ill 

ct2defnS(2L  =  CY_Finance(3uery  Z  cfldefnSflL 

Call  DisplayStatus (Tbl_FinanceCYi  SflLFrameIndex ) 

Call  BuildAccessTable  (Tbl_FinanceCYT  (2def_FinanceCYi  c(2defnS(2L) 

End  Sub 

Private  Sub  CreateAreaFacIDTempTable () 

cProcName  =  "CREATE_AREA__FACID_TEnP_TABLE" 

.  Dim  c(3defnSi2L  As  String 

'Create  Interim  Table  E  AREA__FACID  3 

ci2defnS(3L  =  AreaFacIDConvertfluery 

Call  DisplayStatus  (Tbl_AreaFacIDs T  S(2LFrameIndex  ) 

Call  Bui IdAccessTable  ( Tbl_AreaFacIDs T  (3def_AreaFacIDsi  c(2defnSflL) 
End  Sub 

Private  Sub  CreateAreaUICTempTable () 

cProcName  =  "CREATE_AREA  JIC^TEHP^TABLE" 

Dim  c(3defnS(2L  As  String 

'Create  Interim  Table  t  AREAJIC  3 
ct3defnS(3L  =  AreaUIC(2uery 

Call  DisplayStatus (Tbl_AreaUICs T  S(3LFrameIndex ) 

Call  BuildAccessTable  (Tbl_AreaUICsn  (2def_AreaUICs -i  c(3def nSCL) 

End  Sub 

Private  Sub  CreateAreaClosUICTempTable ( ) 
cProcName  =  "CREATE^AREA  JIC_TE!1P„TABLE” 

Dim  c(3defnSt3L  As  String 

'Create  Interim  Table  C  AREA_CLOS_UIC  3 
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c(3defnS(3L  =  AreaClosUICfluery 

Call  DisplayStatus  (Tbl^AreaClosUICsi  S(3LFrameIndGX ) 

Call  Bui IdAccGSsTable ( Tbl_AreaClosUICs T  (3dGf_ArGaClosUICs n  cfldGfnSflL) 

End  Sub 

Private  Sub  CreatGAreaZipCodeTGmpTablG ( ) 
cProcNamG  =  ”CRE  ATE_AREA_UIC_TEI1P_TABLE" 

Dim  ct3dGfnS(3L  As  String 

^Create  Interim  Table  E  AREA_ZIPCODE  J 

cfldefnSflL  =  AreaZipCodeConverttSuery 

Call  DisplayStatus (Tbl__AreaZipCodesT  SflLFrameIndex ) 

Call  BuildAccessTable  (Tbl__ArGaZipCodes T  (2def_AreaZipCodes t  crSdefnStJL) 

End  Sub 

Private  Sub  CreateAreaGlfiZipTempTable ( ) 
cProcName  =  "CREATE_AREA_UIC_TEnP_TABLE” 

Dim  c(2dGfnS(3L  As  String 

'Create  Interim  Table  E  AREA_Glfl_ZIP  J 
ct2defnS(3L  =  AreaGlflUICZiptSuery 

Call  DisplayStatus (Tbl^AreaGlfiUICZips T  SflLFramelndex ) 

Call  BuildAccessTable  (Tbl_AreaGlfiUICZipST  f2def_AreaGlflUICZips  i  cfldefnSlSL) 

End  Sub 

Private  Sub  CreateAreaGlflllOSTempTable  ( ) 
cProcName  =  ”CREATE_AREA_UIC_TEnP_TABLE” 

Dim  cc3defnS(3L  As  String 

'Create  Interim  Table  E  AREA_G1S_M0S  31 
c(3dGfnSr3L  =  AreaG3iaUICZipriOS<3uery 

Call  DisplayStatus (Tbl^AreaGlfiUICZipHOS T  ScSLFramelndex ) 

Call  BuildAccessTableCTbl^AreaGlflUICZipnOSi  fldef^AreaGlflUICZipnOS i  cfldefnSflL) 
Call  ElapsedTimer ( Time^ ( ) ) 

End  Sub 

Private  Sub  DeleteTempAccessTables ( ) 

cProcName  =  "DELETE_TEnP_ACCESS_TABLES” 

Call  DeleteAccessTable  (Tbl^flOSInterest) 

Call  DeleteAccessTable  ( Tbl_NoASSNx!10S ) 

Call  DeleteAccessTable ( Tbl_FinanceCY ) 

Call  DeleteAccessTable  (Tbl_AreaClosLJICs) 

Call  DeleteAccessTable (Tbl_AreaFacIDs) 

Call  DeleteAccessTable (Tbl_AreaUICs) 

Call  DeleteAccessTable (Tbl_AreaZipCodes) 

Call  DeleteAccessTable (Tbl_AreaGlfiUICZips) 

Call  DeleteAccessTable  ( Tbl_AreaGlflUICZipriOS) 

End  Sub 

Private  Sub  OutputComputedMeasures (ByRef  aHeasuresO  As  MGasures_Type-i  _ 

ByVal  iFacIndex  As  Byte) 

cProcName  =  "OUTPUT_COI1PUTED_nEASURES" 

Dim  i  As  Byte 

'Output  Computed  Measures 
With  AriesStatusBar 

. Panels ( 1) • Text  =  OutputneasuresMSG 

Call  OutputrieasuresGrid  (aMeasures  ( )  T  iFacIndex) 

Call  OutputAriesHeasuresExcel  (afleasures  ()  T  iFacIndex) 

DoEvents 

For  i  =  0  To  iFacIndex 

Call  OutputAriesFacilityInfo  (afleasures  (  i) ) 

Next  i 

. Panels (1 )- Text  =  LDULaunchMSG 
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tabAriesMap . Tab  =  5 
f  raLDliIcntrl .  Visible  =  True 
End  With 
Refresh 
End  Sub 

Private  Sub  OutputAriesFacili tyinf o (ByRef  aHeasures  As  Measures^Type ) 
cProcName  =  '’0UTPUT_ARIES_I1EASURES_TABLE" 

Dim  i  As  Byte  'Loop  Variable 

Dim  rsArchivedFacility  As  Recordset 
Dim  (2defnS(2L  As  String 

(2defnSi3L  =  Archi  vedFaci  1  ityflueryBegin  &  aHeasures  -  FacID  & 
ArchivedFacil ityflueryEnd 

AriesStatusBar  -  Panels  (1  )■  Text  =  Output ArchiveflSG 
Refresh 


'Open  Facility  Respository  Database 

Set  rsArchivedFacility  =  dbTel iko • OpenRecordset (Tbl_AriesArchive i 
dbOpenDynaset ) 

If  Not  aHeasures . Archived  Then 

Call  ArchiveFacilityHeasures (rsArchivedFacility!  aHeasures) 

Elself  Not  aHeasures . HovUIC_Hatch  Then 


Call  ArchiveFacilityHeasures (rsArchivedFacility !  aHeasures) 
End  If 

'Delete  Database  Objects 
Set  rsArchivedFacility  =  Nothing 
End  Sub 


Private  Sub  ArchiveFaciiityHeasures (ByRef  aHeasures  As  Heasures_Type ) 


r 


r 

f 

f 


With  rsHeasures 
• AddNew 

'Transfer  Heasures  to  Proposed  Facility 
!Fac_ID  =  aHeasures - FacID 
JF’AC^HAINT  =  aHeasures  •  FacBacklogdHaint 
!FAC_0PC0ST  =  aHeasures - OperatingCost 
!FAC_AGE  =  aHeasures - FacAge 
!FAC_C0ND  =  aHeasures . FacCond 
!FAC_0WNED  =  aHeasures ■ FacOwned 
ICOHPETION  =  aHeasures. Competition 
!DRILL_ATND  =  aHeasures . AreaDri 1 1 Attend 
!AREA__L0SS  =  aHeasures .  AreaLossRate 
!AREA_XFER  =  aHeasures - AreaXferRate 
!AVG__HANING  =  aHeasures .  A  vgAreaHan 
!DIST_RZA  =  aHeasures. DistToRecruit 
!AVAIL_CLOS  =  aHeasures - Total  A vai IClos 
!IRR  =  aHeasures . IRR 
!REC_HARKET  =  aHeasures . RecruitHarket 
!REASSIGN  =  aHeasures . Reassignments 
!DIST_AHSA  =?  aHeasures  -  DistToAHSA 
!DIST_ECS  =  aHeasures. DistToECS 
!WKND_USED  =  aHeasures . FacUkndUsed 
!H0S_AVAIL  =  aHeasures . HOSAvai IClos 
!IRR__H0S  =  aHeasures. IRRJOS 
IHovUIC  =  cHovUic-UIC 


Record 


' Heasure 

#0 

' Heasure 

#1 

'Heasure 

#2 

' Heasure 

#3 

' Heasure 

#M 

' Heasure 

#5 

' Heasure 

#L 

' Heasure 

#7 

' Heasure 

#fl 

' Heasure 

#T 

' Heasure 

#10 

' Heasure 

#11 

' Heasure 

#12 

'  Heasure 

#13 

'Heasure 

#m 

'Heasure  #15 

' Heasure 

#1L 

' Heasure 

#17 

'Heasure 

#lfl 

'Heasure 
'Heasure  #20 


'Save  Changes  to  Database 
.  Update 
End  With 
End  Sub 


Private  Sub  OutputHeasuresGrid (ByRef  aHeasuresO  As  Heasures_Type n  ByVal  Index 
As  Byte) 

cProcName  =  '^OUTPUT_HEASURES_GRID” 

Dim  i  As  Long 
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Call  InitfleasuresGrid  (Index ) 


Uith  gridfleasures 

For  i  =  D  To  Index 
-Col  =  i  +  1 
-Row  =  D 

-Text  =  aMeasures ( i ) - FacID 
-Row  =  1 

-Text  =  aMeasures ( i )- FacBacklogdMaint 
-Row  =  E 

-Text  =  aMeasures ( i )- OperatingCost 
-Row  =  3 

-Text  =  aMeasures ( i )- FacAge 
-Row  =  M 

-Text  =  aMeasures ( i )- FacCond 
-Row  =  S 

-Text  =  aMeasures ( i )- FacOwned 
-Row  =  ti 

-Text  =  aMeasures ( i) -  Competition 
-Row  =  7 

-Text  =  aMeasures ( i )- AreaDri llAttend 
-Row  =  fi 

-Text  =  aMeasures ( i )- AreaLossRate 
-Row  =  T 

-Text  =  aMeasures ( i ). AreaXferRate 
-Row  =  ID 

-Text  =  aMeasures ( i ). AvgAreaMan 
-Row  =  11 

-Text  =  aMeasures (i) -DistToRecruit 
-Row  =  IS 

-Text  =  aMeasures(i) -TotalAvailClos 
-Row  =  13 

-Text  =  aMeasures ( i )- IRR 

.Row  =  m 

-Text  =  aMeasures ( i )- RecruitMarket 
-Row  =  IS 

-Text  =  aMeasures ( i ). Reassignments 
-Row  -  Ifej 

-Text  =  aMeasures ( i )- DistToAMSA 
-Row  =  17 

-Text  =  aMeasures (i )- DistToECS 
-Row  =  Ifl 

-Text  =  aMeasures  (  i )- FaclilkndUsed 
-Row  =  n 

-Text  =  aMeasures ( i )- MOSAvailClos 
-Row  =  SO 

-Text  =  aMeasures ( i )- IRR_M0S 
Next  i 
End  Uith 
End  Sub 

Private  Sub  EnableLDUbuttons ( ) 

cProcName  =  ”ENABLE_LDU_BUTTONS" 

tbararies-Buttons("matrix”) -Enabled  =  True 
tbararies  - Buttons ("hierarchy”) -  Enabled  =  True 
tbararies - Buttons ( "dynamic" )- Enabl ed  =  True 
tbararies - Buttons ("stacked” ) -Enabled  =  True 
End  Sub 

Private  Sub  Compact AriesDataBase ( ) 

cProcName  =  "COMPACT_ARIES__DATABASE" 

'Compact  the  Acropolis  Database 
Set  dbAcropolis  =  Nothing 

DBEngine - CompactDatabase  App-Path  &  FILE_Acropol is n  App-Path  &  FILE_Akron 
Kill  App-Path  &  FILE_Acropol isBackup 

210 


Nam0  App.Path  &  FILE_Acropol is  As  App.Path  &  FILE_Acropol isBackup 
Name  App.Path  &  FILE_Akron  As  App.Path  &  FILE_Acropolis 

'Compact  the  Repository  Database 
Set  dbTeliko  =  Nothing 

DBEngine. CompactDatabase  App.Path  &  FILE_Telikoi  App.Path  a  FILE_Titan 
Kill  App.Path  a  FILE_TelikoBackup 

Name  App.Path  a  FILE_Teliko  As  App.Path  a  FILE_TelikoBackup 
Name  App.Path  a  FILE_Titan  As  App.Path  a  FILE_Teliko 

Call  Displayllessage (DatabaseCompactedHSCn  vbinf ormationi  vbOKOnlyi 
conFileCaption) 

End  Sub 
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Module  3.  ARIES  PUBLIC  DECLARATIONS 


Purpose:  Initializes  all  public  variables  and  constants;  Contains  the  variables  that  represent 

the  SQL  business  rules  for  calculating  the  ARU-DM  decision  parameters. 

Source  Type:  Visual  Basic  for  Applications 

Source  File:  libDECLARATIONS.BAS 


Code  Listing: 

Attribute  VB„Name  =  "libDECLARATIONS” 
Option  Explicit 


Aries  Status  Bar  Messages 


Public  Const  flovUICstatbarHSG  =  ”Enter  Moving  Unit's  (UIC)” 

Public  Const  MovUIClengthMSG  =  "Moving  UIC  must  be  six  ^  _ 

&  "Alpha-Numeric  characters" 

Public  Const  FacilityStatbarMSG  =  "Enter  Facility  Identifier  "  _ 

&  "for  Proposed  Facility  "  ‘ 

Public  Const  FacIOlengthMSG  =  "Proposed  Facility  Identifier  "  _ 

&  "must  be  entered  in  I  XX###  >  Format" 

Public  Const  LaunchAr iesMSG  =  "Select  ARIES  button  to  start  "  _ 

&  "Facility  Compar isions" 

Public  Const  S(3LStatusMSG  =  "Calculating  Measures  for  Facility  :  " 

Public  Const  ClearButtonMSG  =  "Clears  all  User  Entries" 

Public  Const  ExitButtonMSG  =  "Ends  Program" 


'  S(2L  Status  Display  Messages 


Public  Const  Archi vedFaci 1 ityMSG  =  "Checking  ARIES  Respository  for  "  _ 

S;  "Facilities  -  -  - " 

Public  Const  Bui IdMOSInterestMSG  =  "Creating  MOS  of  Interest  Tables---" 

Public  Const  LaunchMapinf oMSG  =  "Loading  Mapinfo  and  USARC  Databases" 

Public  Const  LDlilLaunchMSG  =  "Ready  to  Launch  LDU  a  Import  "  _ 
a  "Measures  Table- 

Public  Const  Output Archi veMSG  =  "Transferring  Measures  Table  to  " 
a  "Aries  Archive---" 

Public  Const  OutputMeasuresMSG  =  "Transferring  Measures  Table  to  "  „ 
a  "EXCEL..." 

Public  Const  LoadingArchiveMSG  =  "Retrieving  Proposed  Facility  :  " 


Message  Box  User  Messages 


Public  Const  APIfailedMSG  =  "Uin3B  API  Connection  FAILED-"  _ 
a  vbCr  a  vbCr  a  "Unable  to  Complete  Operation-" 

Public  Const  Ar iesConf irmMSG  =  "Conduct  Data  Analysis  Comparisions"  _ 
a  "  of  Proposed  Facilities  :" 

Public  Const  DatabaseCompactedMSG  =  "ARIES  Databases  have  been  "  _ 
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&  "Compacted  Successfully. 


Public  Const  Dupl icateFaci 1 i tyUSG  =  "Unable  to  Conduct  "  _ 

a  "Analysis."  a  vbCr  a  vbCr  a  "DUPLICATE  FACILITY  PROPOSED" 

Public  Const  FacIDinvalidMSG  =  "1  is  currently  not  on  file  in  "  _ 
a  "the  COflMAND  PLAN  or  USARC  GEOREF  File" 

Public  Const  Inval idCISiSuerynSG  =  "Unable  to  Conduct  Analysisi  "  _ 
a  vbCr  a  vbCr  a  "Insufficient  Amount  of  FACILITY(s)  PROPOSED" 

Public  Const  LDUresetMSG  =  "Do  you  wish  to  RESET  the  LDU  Appl icationf "  _ 
a  vbCr  a  vbCr  a  "All  Unsaved  Data  Changes  will  be  Deleted." 

Public  Const  flovUICinvalidtlSG  =  "}  is  currently  not  on  file  in  "  _ 
a  "the  COnnAND  PLAN  or  USARC  GEOREF  File" 

Public  Const  NoFacilityComparedMSG  =  "ARIES  Facility  Comparision  "  _ 
a  "Operation  has  not  been  Performed-" 

Public  Const  OLEf ailedMSG  =  "OLE  Connection  FAILED."  _ 
a  vbCr  a  vbCr  a  "Please  RESTART  Application-" 

Public  Const  CompleteMSG  =  "**  COMPLETE 
Public  Const  AreaGlflMSG  =  "Area  Glfl" 

Public  Const  ArealRRMSG  ==  "Area  IRR" 

Public  Const  Area(3MAMSG  =  "Area  (3MA" 

Public  Const  conNoAuthNG  =  "N0_AUTH„NG" 

Public  Const  CompactDatabaseMSG  =  "Do  you  wish  to  COMPACT  the  Aries  Databases^" 
Public  Const  LDliIacti veMSG  =  "LDbl  Application  currently  not  Activated-" 

Public  Const  Pr interReadyMSG  =  "Ensure  Printer  is  Ready--.." 

Public  Const  Progressindi catorMaxMSG  =  "Progress  Bar  Maximum  Limit  Exceeded" 

Public  Const  conFacilityErrorCaption  =  "Proposed  Facility  Selection" 

Public  Const  conUICcaption  =  "Unit  Identification  Code  Selection" 

Public  Const  conErrorCaption  =  "UNEXPECTED  ERROR  Trap" 

Public  Const  conOLEcaptioh  =  "Windows  TS  OLE  Link  Error". 

Public  Const  conAPIcaption  =  "Logical  Decisions-li)in3B  API  Link" 

Public  Const  conS(2Lcaption  =  "Si2L  (2uery  Computation" 

Public  Const  conFi leCaption  =  "ARIES  File  Maintenance  Operations" 


'  S(2L  (3uery  Definitions  (Temporary  Tables) 

Public  Const  NoASSNxMOSflueryBegin  =  "Select  MOSn  Count(*)  as  "  _ 

&  "M0S_C0UNT  Into  NoASSNxMOS  From  GlSNatl  Uhere  UIC  = 

Public  Const  NoASSNxM0S(2ueryEnd  =  Group  by  MOS  Order  by  " 

&  "CountC*)  DESC" 

Public  Const  M0S_Total(2uery  =  "Select  Sum (M0S_C0UNT)  as  "  _ 

&  "MOS^TOTAL  From  NoASSNxMOS" 

Public  Const  M0S_Top3(3uery  =  "Select  Top  3  M0S_C0UNT  From  "  _ 

&  "NoASSNxMOS" 

Public  Const  M0S_INT_Total(3uery  =  "Select  MOS  Into  "  _ 

R  "MOS^INTEREST  From  NoASSNxMOS  Order  by  MOS" 

Public  Const  M0S_INT_Top3i3uery  =  "Select  Top  3  MOS  Into  "  _ 

R  "MOS^INTEREST  From  NoASSNXMOS  Order  By  MOS" 

Public  Const  CY_Finance(2uery  =  "Select  UICi  Count(UIC)  as  UIC_T0TAL  "  _ 
R  "into  FINANCE_CY  From  FINANCE_(3TR  Where  " 

Public  Const  (31FY_SCRN  =  "(UTA1(31PF  +  UTA2(31PF  +  UTABfllPF  +  "  _ 

R  "UTAM(21PF)  >  2D  Group  by  UIC  Order  by  UIC" 

Public  Const  (32FY_SCRN  =  "(UTA2(31PF  +  UTA3(31PF  +  UTAMfllPF  +  "  _ 
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R  "UTA1(3CFY)  >  EO  Group  by  UIC  Order  by  UIC 


Public  Const  (33FY_SCRN  =  ”(UTA3(31PF  +  UTAM(31PF  +  UTAlflCFY  +  "  _ 

R  "UTAE(3CFY)  >  ED  Group  by  UIC  Order  by  UIC'’ 

Public  Const  (34FY_SCRN  =  "(UTA4(31PF  +  UTAlflCFY  +  UTAE(3CFY  +  ”  _ 

R  "UTAEflCFY)  >  ED  Group  by  UIC  Order  by  UIC" 

Public  Const  AreaFacIDConverti3uery  =  "Select  FAC_II>  Into  "  _ 

R  "AREA_FACID  From  AreaFacIO  Order  by  FAC_I1)" 

Public  Const  AreaZipCodeConvert(3uery  =  "Select  Zip  Into  "  _ 

R  "AREA_ZIPCOI)E  From  AreaZipCode  Order  by  Zip" 

Public  Const  AreaUIC(3uery  =  "Select  Distinct  UIC  Into  AREA_UIC  "  _ 

R  "From  VALIDJIC  Where  VALIDJIC . FAC^ID  =  Any  (Select  "  _ 

R  "AREA_FACID.FAC_ID  From  AREA^FACID)  Order  by  UIC" 

Public  Const  AreaClosUIC(3uery  =  "Select  UIC  Into  AREA_CLOS_UIC  "  _ 

R  "From  G17Natl  Where  Tier  =  '5B»  and  GlTNatl-UIC  =  Any  "  _ 

R  "(Select  AREAJIC.UIC  From  AREAJIC)  Order  by  UIC" 

Public  Const  AreaGlflUICZipfluery  =  "Select  Distinct  UlCn  ZipCodei  "  _ 

R  "Count(UIC)  as  UIC_T0TAL  Into  Area_Gia_ZIP  from  Glfi  "  _ 

R  "Group  by  UlCn  ZipCode  Order  by  UICi  ZipCode" 

Public  Const  AreaGiaUICZipriOS(3uery  =  "Select  Distinct  UICt  ZipCodei  " 
R  "MOSi  Count(UIC)  as  UIC^TOTAL  Into  Area_Gia_nOS  from  Gia  "  _ 

R  "Group  by  UICt  ZipCodei  flOS  Order  by  UICi  ZipCoden  MOS" 


S(3L  (3uery  Definitions  (Temporary  Recordsets) 


Public  Const  NoReqd^2uery  =  "Select  Sum (UIC_T0TAL)  as  T0TAL_RE(3D  "  _ 

R  "From  GnNatl  Where  GnNatl.UIC  =  Any  (Select  AREAJIC .  UIC"  _ 

R  "  From  AREA_UIC)" 

Public  Const  Dri llTotalfluery  =  "Select  Sum ( UIC_T0TAL)  as  DRILL__TOTAL  " 
R  "From  FINANCE^  Where  FINANCE_.UIC  =  Any  (Select  AREAJIC.UIC  "  _ 

R  "From  AREA_UIC)" 

Public  Const  Dri llSAT{3uery  =  "Select  Sum  (UIC^TOTAL)  as  T0TAL_SAT  "  _ 

R  "From  FINANCE_CY  Where  FINANCE^CY . UIC  =  Any  (Select  AREAJIC-UIC 
R  "From  AREA_UIC)" 

Public  Const  NoASSN(3uery  =  "Select  Sum (UIC^TOTAL)  as  TOTAL^ASSN  "  _ 

R  "From  GlBNatlJIC  Where  GiaNatl_UIC  -  UIC  =  Any  "  _ 

R  "(Select  AREAJIC-UIC  From  AREAJIO" 

Public  Const  NoL0SS(3uery  =  "Select  Sum (UIC_T0TAL)  as  T0TAL_L0SS  From  " 
R  "FYxxLOSS  Where  FYxxLOSS-UIC  =  Any  (Select  AREA_UIC.UIC  From  "  _ 

R  "AREA„UIC)" 

Public  Const  NoXFERfluery  =  "Select  Sum (UIC_T0TAL)  as  TOTAL_XFER  From  " 
R  "FYxxXFER  Where  FYxxXFER-UIC  =  Any  (Select  AREA_UIC.UIC  From  "  _ 

R  "AREAJIO" 

Public  Const  TotalAvailClos(2uery  =  "Select  Sum (UIC_T0TAL)  as  "  _ 

R  "TOTAL_AVAIL  From  ArGa_Gia_ZIP  Where  Area_Gia_ZIP - UIC  =  "  _ 

R  "Any  (Select  AREAJIC-UIC  From  AREAJIC)  and  "  _ 

R  "Area^Gia^ZIP. ZIPCODE  =  Any(SGlect  AREA_ZIPCODE.ZIP  From  "  _ 

R  "AREA^ZIPCODE)" 

Public  Const  TotalIRR(2uery  =  "Select  Count(*)  as  T0TAL_IRR  "  _ 

R  "From  IRR  Where  IRR-ZIP  =  Any  (Select  AREA_ZIPCODE.ZIP  "  _ 

R  "From  AREA^ZIPCODE ) " 

Public  Const  Recruitharketfiuery  =  "Select  Sum (nuCATlE+nWCAT3A+"  _ 
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&  "nBCATlS  +  nBCAT3A+nHCAT12+nHCAT3A)  as  TOTALJARKET  From  ”  _ 

8;  ”(3nA  hlhere  (SHA-ZIP  =  Any  (Select  AREA„ZIPCODE .  ZIP  "  _ 

&  "From  AREA_ZIPCOI>E)" 

Public  Const  Reassign(3ueryBegin  =  "Select  Sum (UIC_T0TAL)  as  "  _ 

5  "TOTAL_RESERVISTS  From  Area_Gl.fl„ZIP  Where  "  _ 

6  "Area^Gia^ZIP.UIC  = 

Public  Const  ReassignfiueryEnd  =  and  Area_Glifl_ZIP ■  ZIPCODE  =  "  _ 
a  "Any  (Select  AREA_ZIPCODE.ZIP  From  AREA^ZIPCODE ) " 

Public  Const  TotalClosf10S(2uery  =  "Select  Sum (UIC_T0TAL)  as  "  _ 
a  "TOTAL^CLOSJOS  From  Area_Gia_n0S  Where  Area_G].6_I10S  -  hOS  "  _ 
a  "=  Any  (Select  n0S_INTEREST . nOS  From  MOSJNTEREST)  and  "  „ 
a  "Area_Gia_nOS.UIC  =  Any  (Select  AREA_CLOS_UIC.UIC  From  "  _ 
a  "AREA_CLOS_UIC)  and  Area_GlS_f10S - ZIPCODE  =  Any  (Select  "  _ 
a  "AREA_ZIPCODE.ZIP  From  AREA^ZIPCODE)" 


Public  Const  TotalIRR_nOS(3uery  =  "Select  CountdIOS)  as  "  _ 
a  "TOTAL_IRR_nOS  From  IRR  Where  IRR-MOS  =  Any  (Select  "  _ 
a  "nOS_INTEREST.nOS  From  flOS^INTEREST ) " 


Public  Const  Archi vedFaci lityflueryBegin  =  "Select  t  From  Repository  Where  FAC_II> 

=  I 

Public  Const  Archi vedFaci lityflueryEnd  =  Order  by  flOVUIC" 


Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 


(2def_AreaClosUICs  =  "Build  AreaClosUIC" 
(2def_AreaUICs  =  "Build  AreaUIC" 
(2def_AreaFacIl)s  =  "Build  AreaFacIO" 
fldef^AreaGlfiUICZipnOS  =  "Build  AreaGlfiflOS" 
(3def_AreaGlflUICZips  =  "Build  AreaGlfiZip" 
(3def__AreaZipCodes  =  "Build  AreaZipCode" 
(2def_I)ropTable  =  "Drop  Table" 
(2def__FinanceCY  =  "Build  FinanceCY" 
(2def_!10SInterest  =  "Build  hOSInterest" 
fldef^NoASSNxnOS  =  "Build  NoASSNxMOS" 


Acropol 


Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 
Public  Const 

Public  Const 
Public  Const 
Public  Const 
Public  Const 


is  Database  Table  Names 


Tbl_AreaClosUICs  =  "AREA_CLOS_UIC" 
Tbl_AreaFacIDs  =  "AREA_FACID" 
Tbl_AreaGiaUICZipnOS  =  "AREA^Gia^flOS" 
TbLAreaGiaUICZips  =  "AREA„G].a_ZIP" 
Tbl^AreaUICs  =  "AREAJIC" 
Tbl_AreaZipCodes  =  "AREA_ZIPCODE" 
Tbl_AriesArchive  =  "REPOSITORY" 
Tbl_CommandPlan  =  "CfIDPLAN" 
Tbl^Complex  =  "COMPLEX." 

Tbl_ErrorLog  =  "ERROR.LOG" 
Tbl.FinanceCY  =  "FINANCE.CY" 

Tbl.FPS  =  "FPS_" 

Tfal.GlTNatl  =  "GlTNatl" 

Tbl.Interest  =  "INTEREST." 
Tbl.MOSInterest  =  "MOS.INTEREST" 
Tbl.NoASSNxMOS  =  "NoASSNxMOS" 
Tbl.RPINFODT  =  "RPINFODT." 
Tbl.ValidateUIC  =  "VALID.UIC" 
Tbl.ValidateUnit  =  "VALID.UNIT" 

ExTbl.AreaDistance  =  "AreaDistance" 
ExTbl.AreaFacIDs  =  "AreaFacID" 
ExTbl.AreaUICs  =  "AreaUIC" 
ExTbl.PropFacility  =  "PropFacID" 


V 

r 

r 


Aries  OLE  Class  Names 
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Public  Const  Class_LDU  =  "OwlUindow” 

Public  Const  Class^flaplnf o  =  "xvtBEDmditaskiaG" 
Public  Const  Class_ExcGl  =  "XLMain” 

Public  Const  Class_ARIES  =  "ThunderForm” 

Public  Const  ARIES^Appl ication  =  "A  R  I  E  S  v3.D 


'  Aries  UinAPI32  Constants 

Public  Const  SU_Normal  =  3 
Public  Const  Sbl_ninimum  =  2 


»  Aries  Measure  Table  Names 

Public  Const  conMeasureO  =  "Facility  ID" 

Public  Const  conMeasurel  =  "Backlogged  Maint" 
Public  Const  conneasure2  =  "Operating  Cost" 

Public  Const  conriGasure3  =  "Facility  Age" 

Public  Const  conHeasureM  =  "Facility  Condition" 
Public  Const  conMeasureS  =  "Facility  Owned" 

Public  Const  conMeasureb  =  "Competition" 

Public  Const  conMeasure?  =  "Drill  Attendance" 
Public  Const  conl1easure6  =  "Area  Loss  Rate" 

Public  Const  conHeasureT  =  "Area  Xfer  Rate" 

Public  Const  conMeasurelO  =  "Avg  Area  Manning" 
Public  Const  conMeasurell  =  "RZA  Distance" 

Public  Const  conMeasurel2  =  "Total  Avail  (Close)" 
Public  Const  conMeasurel3  =  "IRR" 

Public  Const  conMeasurelM  =  "Recruit  Market" 

Public  Const  conMeasurelS  =  "Reassignments" 

Public  Const  conMeasurelb  =  "AMSA  Distance" 

Public  Const  conMeasurel?  =  "ECS  Distance" 

Public  Const  conMeasurelfi  =  "bJeekend  Usage" 

Public  Const  conMeasurel^  =  "MOS  Avail  (Close)" 
Public  Const  conMeasureEQ  =  "IRR  MOS" 

Public  Const  conTotalMeasures  =  20 
Public  Const  conTotallnterimTables  =  17 
Public  Const  conSingleMessages  =  3 
Public  Const  conMaximumColumns  =  M 
Public  Const  conFiveColumnblidth  =  lb? 

Public  Const  conFourColumnblidth  =  1210 
Public  Const  conThreeColumnlilidth  =  lb30 
Public  Const  conTwoColumnUidth  =  EMbO 
Public  Const  conOneColumnUidth  =  1370 
Public  Const  MeasuresFrameIndex  =  0 
Public  Const  NonGISFrameIndex  =  1 
Public  Const  Mapinf oFrameIndex  =  2 
Public  Const  GISNonS(3LFrameIndex  =  3 
Public  Const  StJLFramelndex  =  M 


'  Aries  Error  Handler  Codes 

Public  Const  ERR_0b jectExists  =  3012 
Public  Const  ERR^TableExists  .=  3010 
Public  Const  ERR^TableNotExists  =  337b 
Public  Const  ERR_ExtrnTableNot Attached  =  3076 
Public  Const  ERR_Fi leNotFound  =  S3 
Public  Const  ERR__LockTableFai lure  =  3211 
Public  Const  ERR_ProgressBarMaxExceeded  =  360 
Public  Const  ERR_LDURunning  =  S 
Public  Const  ERR_TooFewParameters  =  30bl 
Public  Const  ERR^InvalidUseOFNull  =  TM 
Public  Const  ERR_NoCurrentRecord  =  3021 
Public  Const  ERR^ReqdFi lelndexMissing  =  3015 
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Public  Const  ERR_0b jectUnloaded  =  3tiM 
Public  Const  ERR^NotVal idPath  =  3DMM 
Public  Const  ERR^PatabaseAlreadyOpen  =  33Sh 
Public  Const  ERR^ItemNotlnCol lection  =  32laS 

Public  Const  Def aultErrorValue  =  -'m 


Aries  Pile  Paths 


Public  Const  PILE_Akron  =  "\nS__Access\Akron.MDB” 

Public  Const  PILE_Acropolis  =  ”\nS_Access\Acropol is . MDB" 

Public  Const  FILE_AcropolisBackup  =  "\MS_Access\Acropol is . BAK" 
Public  Const  FILE_l1a jorCity  =  "\HapBasic\napInf o\City__lE5 . TAB" 
Public  Const  FILE^EROS  =  "\nS__AccGss\Eros - flDB" 

Public  Const  FILE^Excel  =  "\LD(i)\nS_Excel\AriesTAB . TXT" 

Public  Const  FILE^GeoREF  =  "\napBasic\UsarcData\Georef - TAB" 

Public  Const  FILE^LDbl  =  "C:\LDliI\LDlilstud.EXE" 

Public  Const  FILE_L])li)_TGniplate  =  "\LDIJ\Template\NULL_TAB . LDIil" 
Public  Const  FILE^LDU^Excel  =  "\LDU\nS_ExcGl\AriesTAB.TXT-" 

Public  Const  FILE_LDU_I>ef aultSave  =  "\LDlil\Template\Def ault - LDlil-" 
Public  Const  FILE_LDIi)_Archi veDir  =  "\LDliI\ArchivG\" 

Public  Const  FILEJapBasic  =  "XHapBasicNAriesArch . HBX" 

Public  Const  FILEJapInfo  =  "C :  XnAPINFOXflapInf  oli)  -  EXE" 

Public  Const  FILE^MapWorkspace  =  "\napBasic\AriGsS(3L -liIOR" 

Public  Const  FILE_States  =  "NMapBasicNMapInf oXStates . TAB" 

Public  Const  FILE^StateCapi tals  =  "MlapBasicNHapInf oXStatecap . TAB" 
Public  Const  FILE_Teliko  =  "\nS_Access\Tel iko . MDB" 

Public  Const  FILE^TelikoBackup  =  "\nS_Access\Teliko . BAK" 

Public  Const  FILE_Titan  =  "\nS_Access\Titan . flDB" 

Public  Const  I>B_ACR0P0LIS  =  "\nS_ACCESS\ACROPOLIS .  tndb" 

Public  Const  DB^ACROPOLISBAK  =  "\nS_ACCESS\ACROPOLIS . bak" 

Public  Const  DB^HEASURES  =  "\nS_ACCESS\rieasures  - mdb" 


'  Aries  deasures  (User  Defined  Type) 

Type  neasures_Type 

Archived  As  Boolean 
dovUIC^datch  As  Boolean 
FacID  As  String  *  S 
FacBacklogddaint  As  Single 
OperatingCost  As  Single 
FacAge  As  Integer 
FacCond  As  String  ♦  5 
FacOwned  As  String  *  1 
Competition  As  Integer 
AreaDrillAttend  As  Single 
AreaLossRate  As  Single 
AreaXferRate  As  Single 
AvgAreadan  As  Single 
DistToRecrui t  As  Single 
Total AvailClos  As  Integer 
IRR  As  Integer 
Recrui tdarket  As  Long 
Reassignments  As  Integer 
DistToAdSA  As  Single 
DistToECS  As  Single 
FacUkndUsed  As  Byte 
dOSAvailClos  As  Integer 
IRR_dOS  As  Integer 
End  Type 

Type  dovingUnit_Type 
UIC  As  String  *  b 
FacID  As  String  *  S 
UnitName  As  String 


City  As  String 
State  As  String  *  S 
ZipCode  As  String  *  S 
End  Type 

Type  Faci lity_Type 

FacID  As  String  t  5 
City  As  String 
State  As  String  *  2 
ZipCode  As  String  *  S 
End  Type 

Type  Inf oTool_Type 

MapTable  As  String 
CeoFacID  As  String 
End  Type 
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Module  4.  ARIES  PROCEDURES  LIBRARY 


Purpose:  A  library  module  that  contains  all  the  procedures  called  by  other  procedures  more 

than  one  time. 

Source  Type:  Visual  Basic  for  Applications 
Source  File:  LIBRARY.BAS 
Code  Listing: 


Attribute  VBJame  =  ’’libPROCEDURES” 

Declare  Function  GetClassNameS  Lib  "user32"  Alias  "GetClassNameA”  _ 

(ByVal  hwnd  As  Longi  ByVal  IpClassName  As  String-i  ByVal  nMaxCount  As  Long) 

Declare  Function  ShowldindowS  Lib  ”user3S”  _ 

(ByVal  hwnd  As  Longi  ByVal  nCmdShow  As  Long) 

Declare  Function  Findlilindow&  Lib  ”user32”  Alias  "FindUindowA”  _ 

(ByVal  IpClassName  As  String-i  ByVal  IpUindowName  As  String) 

Public  Function  KeyUpperNumeric(nKeyVal  As  Integer)  As  Integer 
cProcName  =  ”FUNC :  KEYJPPER^NUMERIC" 

'Passes  Uppercase  Letters 
'Converts  Lowercase  to  Uppercase 
'Passes  •CDnl*i2i3TMiS'»bn7TfiTT}  &  Cntrl  Codes 
'REJECTS  ALL  else 

If  nKeyVal  >  Eh  Then 

If  Chr(nKeyVal)  >=  "a"  And  Chr(nKeyVal)  <=  ”2"  Then 
nKeyVal  =  nKeyVal  ~  32 
End  If 

If  Chr(nKeyVal)  >=  ”A"  And  Chr(nlCeyVal)  <=  "Z”  Then 
nKeyVal  =  nKeyVal 
Else 

nKeyVal  =  KeyNumeric(nKeyVal ) 

End  If 
End  If 

KeyUpperNumeric  =  nKeyVal 
End  Function 

Private  Function  KeyNumeric (nKeyVal  As  Integer)  As  Integer 
cProcName  =  ”FUNC :  KEY^NUriERIC" 

Dim  cValidNumeric  As  String 

cVal  idNumeric  =  ”01E3M5h7a'l” 

If  nKeyVal  >  Eh  Then 

If  InStr ( cValidNumericn  Chr (nKeyVal ) )  =  Q  Then 
nKeyVal  =  D 
End  If 
End  If 

KeyNumeric  =  nKeyVal 
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End  Function 


Public  Function  Val idatetlovUIC (ByVal  cUIC  As  String)  As  Boolean 
cProcName  =  ”FUNC :  VALIDATE^noVUIC*^ 

Dim  rsValidateMovUIC  As  Recordset 

'Develop  Criteria  for  Search 
Val idateHovUIC  =  True 

'Open  Validation  Table 

Set  rs Val idateflovUIC  ==  dbAcropolis  -  OpenRecordset  (Tbl_ValidateUICn 
dbOpenTablen  dbReadOnly) 

With  rsVal idatetlovUIC 
.Index  =  ”UIC” 

.Seek  cUIC 

'Examine  Table  for  first  occurance  of  Moving  Unit  UIC 
If  .NoMatch  Then 

ValidateMovUIC  =  False 

Else  'Get  Facility  Information 

cMovUic . FacID  =  !Fac_ID 
cMovUic . Uni tName  =  !UnitName 
cMovUic.City  =  !City 
cMovUic . State  =  !State 
cMovUic . ZipCode  =  !2ip 
End  If 
.  Close 
End  Uith 

'Delete  Recordset  Object 
Set  rsVal idateMovUIC  =  Nothing 

End  Function 

Public  Function  Val idateFacID (ByVal  cFacID  As  Stringi  __ 

ByRef  rsVal idateFacID  As  Recordset)  As  Boolean 
cProcName  =  "FUNC : VALIDATE_FACID” 

'Develop  Criteria  for  Search 
rsValidateFacID . Seek  cFacID 

'Examine  Table  for  first  occurance  of  FACID 
If  rsValidateFacID . NoMatch  Then 
Val idateFacID  =  False 
Else 

Val idateFacID  =  True 
End  If 

End  Function 

Public  Function  ComputeFacilityAge(ByVal  DateAcquired  As  Date)  As  Integer 
cProcName  =  ”FUNC : COMPUTE^FACILITY^AGE" 

Dim  PresentDate  As  Date 

On  Error  Resume  Next 

'Minimum  Facility  Age  Value  (Default) 

ComputeFaci 1 i tyAge  =  0 

'Today's  Date 
PresentDate  =  Now 

If  IsDate ( DateAcquired)  Then  'Valid  Date 

ComputeFaci lityAge  =  DateDif f (”m” i  DateAcquiredi  PresentDate) 

End  If 

End  Function 

Public  Function  DisplayMessage (ByVal  cMsgText  As  Stringn  _ 

ByVal  iMsgIcon  As  Bytei  ByVal  iMsgBtn  As  Bytei  _ 
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cMsgCaption  As  String)  As  Integer 

Displayflessage  =  MsgBox ( cMsgTexti  iMsglcon  +  iHsgStni  cMsgCaption) 

End  Function 

Private  Function  FormatTime (ByVal  iTime  As  Long)  As  String 
Dim  iHour  As  Long 
Dim  iMinute  As  Long 
Dim  iSecond  As  Long 
Dim  iRemainder  As  Long 

FormatTime  =  cflueryStartTime 

iHour  =  iTime  \  3tiD0 

iRemainder  =  (iTime  -  (iHour  *  BLOD)) 

iMinute  =  iRemainder  \  tD 

iSecond  =  iRemainder  -  (iMinute  *  LD) 

If  Len ( CStr ( iHour ) )  =  E  Then 
FormatTime  =  CStr(iHour)  & 

Else 

FormatTime  =  &  CStr(iHour)  a 

End  If 

If  Len(CStr(iMinute) )  =  E  Then 

FormatTime  =  FormatTime  a  CStr ( iMinute )  a 
Else 

FormatTime  =  FormatTime  a  ”0”  a  CStr ( iMinute )  a 
End  If 

If  Len (CStr (iSecond) )  =  E  Then 

FormatTime  =  FormatTime  a  CStr ( iSecond ) 

Else 

FormatTime  =  FormatTime  a  "0”  a  CStr ( iSecond ) 

End  If 

End  Function 

Public  Function  TableNotNULL (ByRef  rsRecord  As  Recordset)  As  Boolean 
cProcName  =  '’FUNC :  TABLE_N0T_NULL” 

On  Error  Resume  Next 

TableNotNULL  =  True 

If  rsRecord - AbsolutePosition  =  -1  Then 
TableNotNULL  =  False 
End  If 

End  Function 

Public  Function  fluerySumNotNULL (ByVal  cSumResult  As  Variant)  As  Boolean 
cProcName  =  ”FUNC :  (3UERY„SUM_N0T_NULL” 

On  Error  Resume  Next 

fluerySumNotNULL  =  True 

If  IsNull (cSumResult)  Then 
(2uerySumNotNULL  =  False 
End  If 

End  Function 

Public  Function  flueryCountNotNULL (ByVal  cSumResult  As  Variant)  As  Boolean 
cProcName  =  "FUNC  :  (3UERY_C0UNT„N0T_NULL” 


On  Error  Resume  Next 
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(3uGryCountNotNULL  =  True 


If  cSumResult  =  D  Then 

(SueryCountNotNULL  =  False 
End  If 

End  Function 

Public  Sub  Traf f icLight (ByVal  Color  As  Long) 
cProcName  =  ”TRAFFIC_LI6HT” 

With  frmAriesnain 
Select  Case  Color 
Case  vbRed 

!  shpRedLite -FillColor  =  Color 
IshpYellowLite-FillColor  =  vbBlack 
! shpGreenLi te • Fil IColor  =  vbBlack 
! cmdAriesBtn -Enabled  =  False 
Case  vbYellow 

! ShpRedLite -FillColor  =  vbBlack 
! shpYel lowLite - Fi llColor  =  Color 
! shpGreenLite - FillColor  =  vbBlack 
! cmdAriesBtn-Enabled  =  False 
Case  vbGreen 

! ShpRedLite -FillColor  =  vbBlack 
! shpYellowLite • Fi llColor  =  vbBlack 
! shpCreenLite - FillColor  =  Color 
! cmdAriesBtn -Enabled True 
Case  vbBlack 

! ShpRedLite -FillColor  =  Color 
! shpYel lowLite - FillColor  =  Color 
! shpGreenLite - Fil IColor  =  Color 
! cmdAriesBtn - Enabled  =  False 
End  Select 
End  Uith 

End  Sub 

Public  Sub  GetPropFaci 1 ityinf o (ByRef  cFaci 1 i tyinf o  As  Facility_TypeT 
ByRef  rsFacilityData  As  Recordset) 
cProcName  =  ”GET_FACILITY_INFO” 

Dim  bValidFacility  As  Boolean 

On  Error  GoTo  EH_GetPropFacInf o 

bValidFacility  =  ValidateFacID ( cFacil ityinf o - FacID n  rsFaci 1 ityData) 

If  bValidFacility  Then 
With  cFaci 1 ityinf 0 

-City  =  rsFaci lityData ! City 
-State  =  rsFacilityData! State 
-ZipCode  =  rsFacilityData! Zip 
End  With 

Call  LoadPropFacilityUICBox (cFaci 1 ityinf 0 -FacID) 

End  If 

Exit  Sub 

EH_GGtPropFacInf o : 

Select  Case  Err-Number 

Case  ERR_Inval idUseOFNul 1 
Resume  Next 

Case  Else  'Trap  all  other  Errors  &  Report 
Call  0utputERR0R_L0G 
Resume  Next 
End  Select 
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End  Sub 


Public  Sub  DisplayPropFacilityInf 0 (ByRef  cFacility  As  Faci 1 ity_Type ) 
cProcName  =  "DISPLAY__FACILITY_INFO" 

With  f rmAriesflain 

! txtPropFacID ■ Text  =  cFacility . FacID 
!  txtCity.Text  cFacility  -  City 
! txtState . Text  =  cFacility-State 
! txtZipCode . Text  =  cFacil ity • ZipCode 
End  With 

Call  DisplayPropFacil ityUnitNames 
End  Sub 

Public  Sub  LoadPropFacilityUICBox (ByRef  cFacID  As  String) 
cProcName  ^  "GET__PROPOSED_FACILITY_UIC_INFO” 

Dim  i  As  Integer 

Dim  rsFacilityUICs  As  Recordset 

Set  rsFacilityUICs  =  dbAcropolis . OpenRecordset (Tbl_ValidateUICn  dbOpenTable*! 
dbReadOnly) 

f  rmAriesflain  !  cboUIC .  Clear 
With  rsFacilityUICs 
-MoveFirst 
Do  Until  -EOF 

If  cFacID  =  !Fac_ID  Then 

f  rmAriesflain  !  cboUIC  •  Addltem  !  UIC 
End  If 
•MoveNext 
Loop 
-  Close 
End  With 

'Test  whether  any  Units  are  assigned 
With  f rmAriesflain 

If  Not  IcboUIC-ListCount  =  □  Then 
icboUIC-Text  =  ! cboUIC - List (0 ) 

Else 

IcboUIC-Text  =  "“NONE-" 

End  If 
-Refresh 
End  With 

Set  rsFacilityUICs  =  Nothing 
End  Sub 

Public  Sub  DisplayPropFacilityUnitNames ( ) 

cProcName  =  "DISPLAY_PR0P0SED_FACILITY_UNITNAf1ES" 

Dim  i  As  Integer 

Dim  rsFacilityInf 0  As  Recordset 

Dim  rsFacilityUnit  As  Recordset 

Set  rsFacilityInf 0  =  dbAcropol is • OpenRecordset (Tbl_ValidateUICn  dbOpenTablen 
dbReadOnly) 

With  f rmAriesflain 

rsFacilityInf 0 - Index  =  ”UIC” 

! IstbxUni tName -  Clear 

If  Not  IcboUIC-ListCount  =  0  Then 

For  i  =  0  To  IcboUIC-ListCount  -  1 

rsFacil ityinf 0  -  Seek  I cboUIC - List ( i ) 

If  Not  rsFacil  ityinf  0  -  Noflatch  Then 

I IstbxUni tName - Addltem  rsFaci 1 ityinf o I UIC  &  vbTab  _ 

S;  rsFacilityInf  0  I  UnitName 

End  If 
Next  i 
Else 
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IcboUIC.Text  =  "-NONE-” 

Set  rsFaci lityUnit  =  dbAcropol is . OpenRecordset ( Tbl_ValidateUnit n 
dbOpenTablei  dbReadOnly) 

rsFacilityUnit-Index  =  "FACIO" 

rsFaci  lityUnit .  Seek  !  txtPropFacII)  •  Text 

If  rsFacilityUnit -NoMatch  Then 

! IstbxUnitName-Addltem  NOT  AVAILABLE 
Else 

IlstbxUnitName.AddItem  rsFacilityUnitlUnitName 
End  If 

rsFaci lityUnit -Close 
End  If 
.  Refresh 
End  With 

rsFaci lityinfo -  Close 
Set  rsFacilityInf 0  =  Nothing 
Set  rsFacilityUnit  =  Nothing 
End  Sub 

Public  Sub  OisplayTreeViewInf  0  CByRef  tllapFacIDs ( )  As  Inf  oTool_TypGT  _ 

ByVal  Index  As  Long) 

cProcName  =  "1)ISPLAY_TREEVIEU_INF0" 

Dim  rsFacilityUICs  As  Recordset 

Dim  bUICExists  As  Boolean 

Dim  nodeGIS  As  Node 

Dim  i  As  Integer 

Dim  j  As  Integer 

Dim  cFacID  As  String  *  S 

ReDim  cKey(Index)  As  String  *  s 

Set  rsFacilityUICs  =  dbAcropolis • OpenRecordset (Tbl_ValidateUIC*i  dbOpenTablei 
dbReadOnly) 

With  frmAriesflain 

! trvGISData - Enabled  * =  True 

Set  nodeGIS  =  !  trvGISData -  Nodes  -  Add  ( i  .  "ROOT"*,  "USARC:GeoREF") 

For  i  =  ClntCIndex)  To  1  Step  -1 
cKey(i)  =  thapFacIDs ( i ) - GeoFacID 
cFacID  =  tnapFacIDs ( i ) . GeoFacID 

Set  nodeGIS  =  !  trvGISData  -  Nodes  .  Add  ( "ROOT" tvwChild-,  CStr  (cKey  ( i ) )  *, 
cFacID) 

nodeGIS • Expanded  =  True 

bUICExists  =  False 
rsFacilityUICs -HoveFirst 
Do  Until  rsFacilityUICs .EOF 

If  cFacID  =  rsFacilityUICs!Fac_ID  Then 

Set  nodeGIS  =  !  trvGISData .  Nodes  -  Add  ( cKey  ( i  ) -,  tvwChildn  i 
rsFacilityUICsIUIC) 

nodeGIS . Expanded  =  True 
bUICExists  =  True 
End  If 

rsFacilityUICs. no veNext 
Loop 

If  Not  bUICExists  Then 

Set  nodeGIS  =  !  trvGISData .  Nodes  .  Add  ( cKey  ( i  )  i  tvwChildi  "None") 
nodeGIS ■ Expanded  =  True 
End  If 
Next  i 

nodeGIS -EnsureVisible 
.Refresh 

rsFacilityUICs -Close 
Set  rsFacilityUICs  =  Nothing 
End  Uith 
End  Sub 
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Public  Sub  LoadMovUIClistbox (ByRef  cMovUic  As  MovingUnit^Type ) 
cProcName  =  "LOADJOVUIC.LISTBOX" 

Dim  iUnitNameLength  As  Byte 
Dim  cUnitName  As  String 

cUnitName  =  criovUic .  UnitName 
iUnitNameLength  =  Len (cUnitName ) 

With  f rmAriesMain ! IstbxMovUIC 
•Clear 

-Enabled  =  True 

•Addltem  "FacID:  "  &  cMovUic • FacID 

•  Addltem  " _ ” 

If  iUnitNameLength  >  Ifi  Then 
-Addltem  Lef t ( cUnitName t  Ifl) 

If  iUnitNameLength  >  3h  Then 

-Addltem  Mid ( cUnitName t  ITi  Ifl) 

-Addltem  Right  (cUnitNamei  (iUnitNameLength  -  3ti)) 

Else 

-Addltem  Right(cUnitNamen  (iUnitNameLength  -  16)) 

End  If 

Else 

-Addltem  cUnitName 
End  If 

-Addltem  " _ ” 

-Addltem  cllovUic  -  City 

-Addltem  cHovUic  -  State  &  "t  ”  &  cflovUic  -  ZipCode 
End  With 
End  Sub 

Public  Sub  LoadFacilityListBox (ByVal  Index  As  Integeri  ByVal  rsValidFacID 
As  Recordseti  ByVal  iUIC_Flag  As  Byte) 
cProcName  =  "LOAD_FACILITY_LISTBOX" 

Dim  iUnitNameLength  As  Byte 
Dim  cUnitName  As  String 

cUnitName  *=  rsVal idFacID  !  UnitName 
iUnitNameLength  =  Len (cUnitName ) 

'Display  Facility  specific  information 
With  frmAriesflain!  1  stbx FacID ( Index ) 

-  Clear 

-Enabled  =  True 
If  iUIC_Flag  =  D  Then 

-Addltem  ”UIC:  "  &  rsVal idFacID ! UIC 
Else 

-Addltem  "UIC:  ”  &  "-NONE-" 

End  If 

•  Addltem  " _ " 

'Parse  Unitname  to  fit  Listbox  w/out  needing  scrollbars 
If  iUnitNameLength  >  Ifl  Then 
-Addltem  Left ( cUnitName n  Ifl) 

If  iUnitNameLength  >  3tj  Then 

-Addltem  Mid ( cUnitName i  l^i  Ifl) 

-Addltem  Right (cUnitNamei  (iUnitNameLength  -  3h)) 

Else 

-Addltem  Right ( cUnitName t  (iUnitNameLength  -  Ifl)) 

End  If 

Else 

-Addltem  cUnitName 
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End  If 


'Display  Cityi  State-i  Zip  information 

•  Addltem  " _ ” 

-Addltem  rsVal idPacID ! City 

•Addltem  rsVal idFacID ! State  &  &  rsValidFacID ! Zip 

End  lilith 
End  Sub 

Public  Sub  DisplayStatus (ByVal  cMessage  As  Stringi  Index  As  Byte) 

With  frmAriesnainIfraStatusCIndex) 

If  Not  -Enabled  Then 
-Enabled  =  True 

-  Refresh 
End  If 

End  lilith 

With  frmAriesHain! IstbxStatus ( Index ) 

If  Not  (-Visible)  Then 
-Visible  =  True 

-  Refresh 
End  If 

If  Not  (Len ( frmAriesdain ! txtStatus ( Index ) )  =  0)  Then 
-Additem  f rmAriesMain ! txtStatus (Index ) -Text 

-  Refresh 
End  If 

End  lilith 

lilith  frmAriesllain  !  txtStatus  (Index) 

-Text  =  cMessage 
-  Refresh 

If  Not  (dlessage  =  CompleteriSG)  Then 
Call  IncrementProgressBar 
Else 

-Enabled  =  False 
-Refresh 
End  If 
End  lilith 

Call  ElapsedTimer(Time$( ) ) 

End  Sub 

Public  Sub  IncrementProgressBar ( ) 

On  Error  Resume  Next 

iProgressIndicator  =  iProgressIndicator  +  1 
f  rmAriesMain  !  barS(2Lstatus  -  Value  =  iProgressIndicator 
frmAriesMainlfraSflLstatus- Refresh 
End  Sub 

Public  Sub  Bui  IdAccessTable  (ByVal  cTableName  As  Stringn  cfldefnName  As  String-i 
c(3defText  As  String) 
cProcName  =  ”BUILD_ACCESS_TABLE" 

Dim  qdS(2L  As  (2ueryDef 

On  Error  GoTo  EH__BuildTable 

'Build  S(3L  (2uery  definition  for  Recordset  Object 

Set  qdSt3L  =  dbAcropol  is  -  CreateflueryDef  ( c(2def  nName -»  cfldefText) 

dbAcropolis - Execute  cfidefnName 

'Delete  (3uery  Definition  S;  Table 
dbAcropolis -flueryDefs- Delete  ct2defnName 

Exit  Sub 
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EH_BuildTable :  'Error  Handler 

Select  Case  Err-Number 

Case  ERR_0b jectExists  'Delete  the  Pre-Existing  fluery  Definition 
dbAcropolis  .  CueryDefs  -  Delete  ctJdefnName 
Resume 

Case  ERR_TableExists  'Delete  the  Pre-Existing  Table 
Call  DeleteAccessTable(cTableName) 

Resume 

Case  Else  'Trap  all  other  Errors  &  Report 
Call  0utputERR0R_L0G 
Resume  Next 
End  Select 
End  Sub 

Public  Sub  DeleteAccessTable (ByVal  cTableName  As  String) 
cProcName  =  ”DELETE_ACCESS_TABLE” 

Dim  qdDropTable  As  (2ueryDef 
Dim  cDropTableDef n  As  String 

On  Error  GoTo  EH_DeleteTable 

cDropTableDef n  =  "Drop  Table  "  &  cTableName 

Set  qdDropTable  =  dbAcropolis • CreateiSueryDef (fldef^DropTablen  cDropTableDef n) 
dbAcropol  is  -  Execute  (2def_Dr  op  Table 

db Aero polis.(3ueryDefs. Delete  fidefJropTable 

Exit  Sub 

EH^DeleteTable: 

Select  Case  Err-Number 
Case  ERR_0b jectExists 

dbAcropolis  -  (3ueryDef  s  -  Delete  fid ef_Drop Table 
Resume 

Case  ERR_TableNotExists 
Resume  Next 

Case  Else 

Call  0utputERR0R_L0G 
Resume  Next 
End  Select 
End  Sub 

Public  Sub  ElapsedTimer (ByVal  cTime  As  String) 

Dim  iHourNow  As  Long 
Dim  iHinuteNow  As  Long 
Dim  iSecondNow  As  Long 

Dim  iStartHour  As  Long 
Dim  iStartninute  As  Long 
Dim  iStartSecond  As  Long 

Dim  iElapsedTime  As  Long 
Dim  iStartTime  As  Long 
Dim  iNowTime  As  Long 

Dim  cElapsedTime  As  String  *  fi 

iHourNow  =  CLng (Lef t (cTime n  2)) 
iHinuteNow  =  CLng (Hid (cTime n  Mn  2)) 
iSecondNow  =  CLng (Right (cTimei  2)) 

iStartHour  =  CLng (Lef t ( cfiueryStartTime t  2)) 
iStartninute  =  CLng (nid(cfiueryStartTimei  Mi  2)) 
iStartSecond  =  CLng (Right (cfiueryStartTime n  2)) 
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iStartTime  =  (iStartHour  *  BbDD)  +  ( iStartflinute  *  tO)  +  iStartSecond 
iNowTime  =  (iHourNow  *  BbDG)  +  (iMinuteNow  *  bD)  +  iSQCondNow 

iElapsedTime  =  iNowTime  -  iStartTime 

cElapsedTime  =  FormatTime ( iElapsedTime ) 

With  f rmAriesMain 

! AriesStatusBar.Panels(3) -Text  =  "Elapsed  ”  a  cElapsedTime 
-  Refresh 
End  lilith 
End  Sub 

Public  Sub  TimeDelay (ByVal  cTirae  As  String-i  _ 

ByVal  iTimeDelay  As  Integer) 
cProcName  =  "TIMEJELAY" 

Dim  iSecond  As  Integer 
Dim  iMinute  As  Integer 
Dim  iNowflinute  As  Integer 
Dim  iNowSecond  As  Integer 

Dim  iExitTime  As  Integer 
Dim  bRolloverFlag  As  Boolean 

bRol loverFlag  =  False 

iSecond  =  CInt(Right (cTimei  2)) 

minute  =  CInt  (Mid  (cTime  1  M  t  B))  +  1 

iExitTime  =  iSecond  +  iTimeDelay 
If  iExitTime  >  ST  Then 

iExitTime  =  iExitTime  -  ST 
bRolloverFlag  =  True 
End  If 

iNowSecond  =  CInt (Right (Time$ () t  2)) 

If  bRolloverFlag  Then 

iNowflinute  =  CInt  (flid  (Time$  ( )  t  Mt  2)) 

Do 

iNowflinute  =  CInt  ( flid  (Time$  ( )  i  Mi  2)) 
iNowSecond  =  CInt (Right (Time$ () t  2)) 

Loop  While  iNowflinute  <  iflinute 
Else 
Do 

iNowSecond  =  CInt (Right ( Time$ () t  2)) 

Loop  While  iNowSecond  <  iExitTime 
End  If 
End  Sub 
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Module  5.  OLE  PROCEDURES  LIBRARY 


Purpose:  A  library  module  that  contains  all  the  procedures  supporting  OLE 

communications  between  COTS  components. 

Source  Type:  Visual  Basic  for  Applications 

Source  File:  OLE_LIBRARY.BAS 

Code  Listing: 


Attribute  VB_Name  =  "libOLE” 

Option  Explicit 

Public  Function  ConnectOLEob ject (ByRef  objOLE  As  Objecti  ByVal  cOLEob jectName 
As  String)  As  Boolean 
cProcName  =  '"FUNC :  OPEN_OLE_OB  JECT” 

On  Error  Resume  Next 

'Set  Boolean  Flags 
ConnectOLEob ject  =  True 
Set  objOLE  =  Nothing 

'Initiate  a  new  instance 

Set  objOLE  =  CreateOb ject ( cOLEob jectName ) 

'Verify  OLE  connection  established 
If  objOLE  Is  Nothing  Then  'OLE  Error 

Call  OisplayMessage (OLEfailedflSGi  vbExclamation n  vbOKi  conOLEcaption) 
ConnectOLEob ject  =  False 
Else 

objOLE - Visible  =  False 
End  If 

DoEvents 

End  Function 

Public  Function  OpenLOliiob  ject ( ) 

cProcName  =  ”FUNC  :  OPEN^LDbl^OB  JECT” 

Dim  cFilePath  As  String 

On  Error  GoTo  EH_OpenLI)U 

OpenLOliiob  ject  =  True 
cFilePath  =  FILE^LOU 

'Oetermine  if  an  Instance  of  LOliI  already  running 
iLOblwinlO  =  Findidindow ( Class_LOIiI t  vbNullString) 

If  iLOWwinlO  Then 

Call  ResetLOUob ject 
Else 

iLOlilwinlO  =  Shell  (cFilePathn  vbNormalFocus ) 
frmAriesMain  !  mnuFCloseLOliI  .Enabled  =  True 
'Clear  LOlil  Splash  Screen 
SendKeys  '’-”-1  True 
End  If 

Exit  Function 

EH^OpenLOU :  'LOU  Failed  to  Load  properly. 

OpenLOUob ject  =  False 
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End  Function 


Public  Function  Verif yLDUob jectConnection (ByVal  cHessageText  As  String)  As 
Boolean 

.  Dim  iLDli)_hljJnd  As  Long 

iLDliI_hUnd  =  FindUindow ( Class_LDU i  vbNul IString ) 

If  iLDU_hUnd  =  □  Then 

Verif yLDUob jectConnection  =  False 

Call  DisplayMessage (criessageTextn  vbCriticali  vbOKOnlyi  conAPIcaption ) 
Else 

Verif  yLDIilob  jectConnection  =  True 
Showliiindow  iLDU^hlilnd i  Slil_t1inimum 
ShowWindow  iLDLJ_hb)nd i  SIJ_Normal 
End  If 

End  Function 

Public  Sub  InitializeflapInfoMenu ( ) 
cProcName  =  "INITIALIZEJAPJENU” 

objGeoSelect -Do  "Create  Menu  ""llapperShortcut""  ID  17  As  »» 

End  Sub 

Public  Sub  Initializeflapinf oToolbar () 
cProcName  =  "INITIALIZE  JAP^TOOLJAR" 

ob jGeoSelect . Do  "Create  ButtonPad  ""InfoTool""  As  "  &  _ 

"ToolButton  ID  5D1  Drawllode  3M  Calling  OLE  ""Processinf oToo IButton"”" 


End  Sub 

Public  Sub  Ini tializeMapInf oStatusBar () 
cProcName  =  "INITIALIZE JAP_STATUS_BAR" 

ob  jGeoSe lect  -  Do  "Set  flap  Display  Zoom" 

ob jGeoSelect - Do  "Alter  Menu  Item  ID  llDl  Check" 

ob jGeoSelect . Do  "Alter  Menu  Item  ID  IIDE  UnCheck” 

ob jGeoSelect - Do  "Alter  Menu  Item  ID  1103  UnCheck" 

End  Sub 

Public  Sub  OpenUS_StatesLayer () 

cProcName  =  "DISPLA Y_US_STATES_LA YER" 

Dim  cFilePath  As  String 

cFilePath  =  Chr(3M)  R  App.Path  &  FILE_States  &  Chr(3H) 
ob jGeoSelect -Do  "Open  Table  "  &  cFilePath  R  "  Interactive" 

End  Sub 

Public  Sub  OpenUSARC__GeoRef Layer  ( ) 

cProcName  =  "DISPLAY_USARC_GEOREF_LAYER" 

Dim  cFilePath  As  String 

cFilePath  =  Chr(3M)  R  App-Path  R  FILE_GeoREF  R  Chr(3M) 
ob jGeoSelect . Do  "Open  Table  "  R  cFilePath  R  "  Interactive" 

End  Sub 

Public  Sub  OpenStateCapitalsLayer ( ) 

cProcName  =  "DISPLA Y_STATE_CAPITALS_LAYER" 

Dim  cFilePath  As  String 

cFilePath  =  Chr(3M)  R  App-Path  R  FILE_StateCapi tals  R  Chr(3M) 
ob jGeoSelect - Do  "Open  Table  "  R  cFilePath  R  "  Interactive" 

232 


End  Sub 


Public  Sub  OpenHa jorCityLayerO 

cProcName  =  "DISPLAY^flA  JOR^CITIES^LAYER" 

Dim  cFilePath  As  String 

cFilePath  =  ChrOM)  &  App-Path  a  FILEJa jorCity  a  Chr(34) 
ob jCeoSelGct - Do  "Open  Table  "  a  cFilePath  a  "  Interactive" 

End  Sub 


Public  Sub  DisplayMapLabels () 

cProcName  =  "DISPLAY_nAP_LABELS" 

ob  jGeoSelect  -  Do  "flap  From  Statecapi  City_125T  Georefi  States" 
iflaplnf  oUinlD  =  CLng  (ob  jGeoSelect  -  Eval  ("Frontlilindow  ( ) " ) ) 
objGeoSelect.Do  "Set  Map  Redraw  Off" 

'State  Capitals  layer  Labels  a  Symbols 

objGeoSelect.Do  "Set  Map  Layer  ""Statecap""  Display  Global  Selectable  Off  ’ 
objGeoSelect.Do  "Set  Map  Layer  ""Statecap""  Label  Auto  On  Overlap  On  "  a  _ 
"Duplicates  On  With  Proper^ (Capital)  " 
ob jGeoSelect . Do  "Set  Map  Layer  ""Statecap""  Label  Line  Simple  ”  _ 

a  "Position  Above  Offset  3  Font  (""Arial""-.  flD3 .fl -.a3aab0fl -.IbTTTElS)  "  _ 
a  "Global  Symbol  (3S-,  ILVlltaDi  la)  " 
ob jGeoSelect-Do  "Set  Map  Layer  ""Statecap""  Label  Visibility  Zoom  (MDDt 
2D0D)"  _ 

a  "  Units  ”"mi""" 


'Major  City  layer  Labels  a  Symbols 

objGeoSelect.Do  "Set  Map  Layer  ""City_lHS""  Display  Global  Selectable  Off  " 
objGeoSelect.Do  "Set  Map  Layer  ""Ci ty__lES""  Label  Auto  On  Overlap  On  "  a  _ 
"Duplicates  On  With  Proper^ ( City )  Zoom  (On  3DDQ)  Units  ""mi""  On  " 
objGeoSelect.Do  "Set  Map  Layer  ""City_12S""  Label  Line  Simple  "  _ 

a  "Position  Above  Offset  3  Font  (""Arial""T  ETlTlOnltiTTfei'lbQTD )  "  _ 
a  "Global  Symbol  (ML-.  ILTTL'ILD-,  IE)  " 
objGeoSelect.Do  "Set  Map  Layer  ""City_lE5""  Label  Visibility  Zoom  (E5D-« 
lODD)"  _ 

a  "  Units  ”"mi""" 


'GeoREF  layer  Labels  a  Symbols 

ob jGeoSelect . Do  "Set  Map  Layer  ""Georef""  Display  Global  Selectable  On  " 
objGeoSelect.Do  "Set  Map  Layer  ""Georef""  Label  Auto  On  Overlap  On  "  a  _ 
"Duplicates  Off  With  Proper^ (Fac_city )  Zoom  (Di  SDO)  Units  ""mi""  On  " 
objGeoSelect.Do  "Set  Map  Layer  ""Georef""  Label  Line  Simple  "  _ 

a  "Position  Above  Right  Offset  3  Font  (""Arial""-i  fiQ3il0n3E7bfl-.lb777E15)" 


a  "  Pen  (E-.m-.3E7Lfi)  Global  Symbol  (MS-.  3E7Lfl-,  16)  " 
objGeoSelect.Do  "Set  Map  Layer  ""Georef""  Label  Visibility  Zoom  (Q-.  7DD)  "  _ 
a  "Units  ”"mi""" 


'States  layer  Labels 
objGeoSelect.Do  "Set  Map  Layer 
objGeoSelect.Do  "Set  Map  Layer 
a  "Duplicates  On  Offset  □  " 
objGeoSelect.Do  "Set  Map  Layer 
objGeoSelect.Do  "Set  Map  Layer 


""States"" 

""States"" 

""States"" 

""States"" 


Selectable  Off  Label  Line  Simple  " 
Label  Auto  On  Overlap  On  "  _ 

Label  Uith  Proper^(State)  " 

Label  Font  (""Bookman  Old  Style""i" 


a  "16E7-,iaiD-.lb777E15)  " 

objGeoSelect.Do  "Set  Map  Layer  ""States"" 


Label  Visibility  Zoom  (lOD-.  EDDB)  " 


a  "Units  "”mi""" 


objGeoSelect.Do  "Set  Map  Redraw  On" 
End  Sub 


Public  Sub  Posi tionMap ( ) 
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cProcName  =  ^POSITION  JAP" 

ob jGeoSelect - Do  "Map  From  Statecapn  City^lSSi  Georefi  States" 
ob jGeoSelect . Do  "Set  Map  Center  Zoom  3SDD  Units 

ob jGeoSelect • Do  "Set  Map  Layer  D  Editable  On" 

End  Sub 

Public  Sub  Mapinf o(3uery (ByVal  cFacID  As  String) 
cProcName  =  "MAPINFOJUERY" 

Dim  i  As  Byte  'Loop  Variable 

Dim  cFilePath  As  String 

Dim  rsProposedFaci 1 i ty  As  Recordset 

Set  rsProposedFacility  =  dbAcropolis  .  OpenRecordset  (ExTblJropFacilityT 
dbOpenDynaset ) 

With  rsProposedFacility 

'Delete  Previous  Proposed  Facilities 
Do  Until  -EOF 
-Delete 
-  MoveNext 
Loop 

'Output  Proposed  Facility  ID  to  External  Database 
•AddNew 

!Fac_ID  =  cFacID 
-Update 
-  Close 
End  With 

Set  rsProposedFacility  =  Nothing 

objGeofluery. Visible  =  True 
If  Not  bMapBasicRunning  Then 

cFilePath  =  Chr(3M)  &  App-Path  S  FILE JapUorkspace  a  Chr(3M) 
objGeo(3uery-Do  "Run  Application  "  a  cFilePath 
End  If 

cFilePath  =  Chr(3M)  a  App-Path  a  FILEJapBasic  a  Chr(3M) 
f rmAriesMain ! tabAriesMap - Tab  =  1 

ob  jGeotSuery  -  Do  "Run  Application  "  a  cFilePath 
bMapBasicRunning  =  True 

Call  DisplayStatus  (AreaGlflMSGn  GISNonS(3LFrameIndex  ) 

Call  DisplayStatus ( ArealRRMSGi  GISNonSfiLFrameIndex ) 

Call  DisplayStatus  ( AreaflMAMSGn  GISNonStJLFramelndex ) 

End  Sub 

Public  Sub  OutputAriesMeasuresExcel (ByRef  aMeasuresC)  As  Measures_Type t  ByVal 
iFacIndex  As  Byte) 

cProcName  =  "OUTPUT_ARIES  ..MEASURES  JXCEL" 

Dim  objtiiorkSht  As  Object 
Dim  cFilePath  As  String 

Dim  i  As  Byte 
Dim  j  As  Byte 

On  Error  GoTo  EH_ExcelMeasures 

Screen - MousePointer  =  vbHourglass 

If  ConnectOLEob ject (ob jExcel T  "Excel  -  Application")  Then 
objExcel - Visible  =  True 
objEx cel  -  Workbooks  -  Add 

Set  objblorkSht  =  objExcel  -  ActiveSheet 
With  objliJorkSht 
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=  "0ist-tO“Recruiter" 

.cells(3n 

IS) 

■Value 

=  "Recruit_Market" 

-  cells (3n 

lb) 

. Value 

=  "Reassignments" 

.cells(3n 

17) 

■  Value 

=  "Fac_Condition" 

-  cells (3  n 

Ifl) 

■  Value 

=  "Competition" 

.cellsOn 

n) 

. Value 

=  "FacJeekend^Use" 

. cells (3  n 

BD) 

■  Value 

=  "Fac_Backlogd_Maint" 

. cells (3 1 

Bl) 

■  Value 

=  "Area_Loss_Rate" 

OoEvents 

For  i  =  D 

To 

iFacIndex 

j  =  i 

+  M 

.cells(jT  1). Value  =  &  aMeasures ( i ) - FacID 

•  cellsCji  2). Value  =  afleasures  ( i )  -  TotalAvailClos 
-cellsCji  3). Value  =  aMeasures ( i )- HOSAvailClos 
-cells(jn  4)-Value  =  aMeasures ( i )- IRR 
•cellsCji  S) ‘Value  =  aMeasures ( i )• IRR_M0S 

•  cellsCj-.  b)-Value  =  aMeasures ( i )■  FacAge 

.cellsCji  7). Value  =  &  aMeasures ( i ). FacOwned 

■cellsCjT  fl). Value  =  aMeasures ( i )• OperatingCost 
•cellsCjn  T)-Value  =  aMeasures ( i )■ DistToAMSA 
•cellsCji  ID). Value  =  aMeasures(i) -DistToECS 
•cellsCji  11). Value  =  aMeasures ( i )• AreaXferRate 
.cells(jT  15). Value  =  aMeasures ( i )- AvgAreaMan 
.cells(jn  13). Value  =  aMeasures ( i ). AreaDri 11  Attend 
.cellsCjn  m). Value  =  aMeasures ( i )• DistToRecruit 
.cellsCjT  15). Value  =  aMeasures ( i ). RecruitMarket 
-cells(jT  lb). Value  =  aMeasures ( i )- Reassignments 
..cells(ji  17). Value  =  &  aMeasures ( i )- FacCond 

.cells(jT  ia)-Value  =  aMeasures ( i ). Competition 
-cellsCjT  n). Value  =  aMeasures  (  i  )- FacliIkndUsed 


•cellsijt  20)-Value  =  aMeasures ( i ) - FacBacklogdUaint 
■  cellsCji  21). Value  =  afleasures  ( i )  .  AreaLossRate 

DoEvents 
Next  i 

-cellsCMn  1). Value  =  ”J0VING  UNIT" 

End  liiith 

cFilePath  =  App-Path  &  FILE_Excel 
SendKeys  ">:FA"t  True 
SendKeys  cFilePathi  True 

SendKeys  True 

SendKeys  "Idownlldownl-Cdownl" -i  True 
SendKeys  True 

SendKeys  "“/'Y-"-.  True 

If  Not  objExcel  Is  Nothing  Then 

objExcel .  ActiveklorkBook  -  Close  False 
End  If 

objExcel .  (3uit 
Set  objExcel  =  Nothing 
End  If 

Screen  -  riousePointer  =  vbDefault 
Exit  Sub 

EH_Exceirieasures : 

Call  0utputERR0R_L0C 
Set  objliJorkSht  =  Nothing 
End  Sub 

Public  Sub  ResetLDUob ject ( ) 

cProcName  =  "RESET^LDIil^OB  JECT" 

If  Verif yLDliiob jectConnection ( APIf ailednSG)  Then 
SendKeys  "^FN"-.  True 
SendKeys  ">CN"i  True 
DoEvents 
End  If 
End  Sub 

Public  Sub  ImportLDbidataC ) 

Dim  cFilePath  As  String 
Dim  iLDlil_hlJnd  As  Long 

If  bLDUactive  Then 

Verif  yLDUob  jectConnection  ( APIf  ail  edfISG) 

'Load  LDb)  Template  File 

cFilePath  =  App-Path  &  FILE_LDIiI_Template 
SendKeys  "/^FO"!  True 
SendKeys  cFilePathi  True 
SendKeys  "-CENTERIIENTERI"-.  True 
DoEvents 

'Import  Excel  Tab  delimited  file 
cFilePath  =  App-Path  a  FILE_LDU_Excel 
SendKeys  "5CFI"-.  True 

SendKeys  "{tabl-Ctabl-Cdownl-Ctabl-Cdownl-Cdownl-CdownlCdownl-'" i  True 
SendKeys  cFilePathi  True 
SendKeys  -i  True 

DoEvents 

Call  SendCommentsLDb) 

'Save  Temp  file  of  Imported  measure  comparisions 
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cFilePath  =  App.Path  S;  FILE_LDliJ_Def aultSave 
SendKeys  ^^FA^t  True 
SendKeys  cFilePathi  True 
SendKeys  True 

DoEvents 
End  If 
End  Sub 

Public  Sub  SendCommentsLDU ( ) 

Dim  rsFaci 1 ityinf 0  As  Recordset 

Dim  i  As  Byte 

Dim  j  As  Byte 

Dim  cFacID  As  String  *  5 

Dim  cCity  As  String 

Dim  estate  As  String  *  E 

On  Error  GoTo  EH_Comment 

Set  rsFaci 1 ityinf 0  =  dbAcropol is . OpenRecordset (Tbl_ValidateUnitT  dbOpenTablei 
dbReadOnly ) 

With  rsFaci lityinfo 
.Index  =  "FACID" 

For  i  =  D  To  ^ 

-Seek  aFacID(i) 

If  Not  -NoMatch  Then 
cFacID  -  !Fac_ID 
cCity  =  !City 
estate  =  !State 

'Send  location  information  to  LDlil 
SendKeys  "V.EM-”-.  True 
For  j  =  0  To  i 

SendKeys  '’•Cdown>'’T  True 
Next  j 

SendKeys  '’-ITabl-CTabl-CTab}'’-,  True 
SendKeys  cFacIDn  True 
SendKeys  True 

SendKeys  cCity  &  "n  ”  &  cStaten  True 
SendKeys  "-Ctablltab}-” 

End  If 
Next  i 
End  liiith 

Set  rsFaci 1 ityinf 0  =  Nothing 

Exit  Sub 

EH_Comment: 

Exit  Sub 
End  Sub 

Public  Sub  ViewLDltlmatrix () 

Dim  iLDliI_hli)nd  As  Long 


If  bLDlilactive  Then 

Verif yLDUob jectConnection  ( APIf ailedMSG) 
DoEvents 

SendKeys  True 

End  If 
End  Sub 

Public  Sub  ActivateLDIilReports  () 

'Print  ARIES  Model  Hierarchy  w/  Global  weights 
SendKeys  ”5JIj)E"t  True 
SendKeys  ”/iH-Cdown}G” t  True 
Call  TimeDelay (Time^ ( ) T  E) 

SendKeys  "/^FP^t  True 

Call  TimeDelay (Time$ ( ) n  S)  '  E  second  delay 
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SendKeys  ” — True 

Call  TimeDelay(Time$() T  13)  '13  Second  delay 

'Print  ARIES  Model  Stacked  bar  ranking 
SendKeys  True 

Call  TimeDelay ( Time$ () 1  2)  'S  Second  delay 

SendKeys  ”-"1  True 
SendKeys  True 

Call  TimeDelay ( Tinie$ ( )  T  S)  'S  Second  delay 

'Print  ARIES  Model  Comment  Summary 
SendKeys  True 

SendKeys  "5'FP"-i  True 

Call  TimeDelay (Time^O T  S)  '5  Second  delay 

'Change  Printer  Setup  for  Landscape  Mode 
SendKeys  "JCFR/JL*-"!  True 

Call  TimePelayCTime^O T  1)  '1  Second  delay 

'Print  ARIES  Model  Preference  Set  Summary 
SendKeys  "/CSP~”i  True 
SendKeys  True 

Call  TimeDelay (Time^ ( ) n  5)  '5  Second  delay 

'Print  ARIES  Model  Ranking  results  matrix 
SendKeys  "5cSMM~'’i  True 
SendKeys  "/CFP”t  True 

Call  TimeDelayCTime^Oi  5)  'S  Second  delay 

'Change  Printer  Setup  for  Portrait  Mode 
SendKeys  "/CFR5cR-"-i  True 
Call  TimeDelay  (Time$  ( )'i  1) 

End  Sub 


'1  Second  delay 


Module  6.  OLE  OBJECT  CLASS  DEFINITION 


Purpose:  An  object  class  description  necessary  for  communicating  with  the  integrated 

Mapinfo  component. 


Source  Type:  Visual  Basic  for  Applications 


Source  File:  OLE_CALLBACK.CLS 


Code  Listing: 


VERSION  1.0  CLASS 
BEGIN 

HultiUse  =  -1  'True 

END 

Attribute  VB^Name  =  "clsOLECallback” 

Attribute  VB_Creatable  =  False 
Attribute  VB_Exposed  =  True 
Option  Explicit 

Private  Function  GetField (ByVal  theStr  As  Stringn  ByVal  delimiter  As  String-i 
ByVal  whichField  As  Integer)  As  String 
cProcName  =  ”FUNC:GET_FIELD” 

Dim  i  As  Integer 
Dim  startPos  As  Integer 
Dim  argCount  As  Integer 
Dim  tmpStrn  result  As  String 

if  the  input  string  was  nulli  or  they  asked  for  a  field  #  less  than  In 
return  an  empty  string  as  the  result 
If  Len(theStr)  =  0  Or  whichField  <  1  Then 
GetField  =  "" 

Exit  Function 
End  If. 

loop  through  til  we  get  the  field  we  want-  If  the  string  contains  fewer 
fields  than  the  field  number  requested!  a  zero-length  string  is  returned. 
argCount  =  0 
tmpStr  =  theStr 

Do 

argCount  =  argCount  +  1 

result  =  Lef t$ ( tmpStr !  InStr (tmpStri  delimiter)  -  1) 
tmpStr  =  nid$  (tmpStr -1  InStr  (tmpStri  delimiter)  +  1) 

Loop  While  InStr (tmpStr t  delimiter)  >  0  And  argCount  <  whichField 

if  we  dropped  out  of  the  while  loop  because  InStr()  returned  Oi  and 

we  haven't  gotten  to  the  desired  field  yeti  take  one  more  step  in  case 

we  are  actually  looking  for  the  last  field  in  the  string. 

If  argCount  <  whichField  Then 

argCount  =  argCount  +  1 

result  =  tmpStr 
End  If 

if  WG  found  our  field!  argCount  will  equal  whichField.  return  the 
result  string!  otherwise!  return  a  zero-length  string 
If  argCount  =  whichField  Then 
GetField  =  result 
Else 
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GetPield  = 

End  If 

End  Function 

'  Processinf oToolButton 

'  This  method  is  called  when  the  custom  tools  defined  in  Mapinfo 

'  in  the  "Initializeflaplnf oConnection”  are  used  in  the  map  window- 

'  This  method  determines  which  tool  was  used  (  a  point  select  tooln 

'  and  a  rectangle  select  tool  ) i  and  performs  the  appropriate  action 

Public  Sub  Processinf oToolButton (ByVal  Commandinf oText  As  String) 
cProcName  =  ”PR0CESS_T00L_BUTT0N" 

Dim  iSelectedButton  As  Integer 
Dim  fXpt  As  Double 
Dim  fYpt  As  Double 
Dim  nHits  As  Long 

'Verify  that  the  Windows  Message  came  from  Mapinfo 

'If  it  did  come  from  Maplnfoi  strip  off  the  ”MI:"  prefix: 

If  Left^ (Commandinf oText T  3)  =  ”MI:"  Then 

Commandinf oText  =  Mid$  ( Commandinf oTexti  Mn 
Else 

Exit  Sub 

End  If  'Determine  which  Tool  Selected 

iSelectedButton  =  CInt (GetPield ( Commandinf oTexti  CMD_INP0_T00LBTN) ) 

Select  Case  iSelectedButton 
Case  SOI  'info  tool 

fXpt  =  CDbl (GetPield (Commandinf oTextn  CMD_INF0_X))  get  x 

and  y 

fYpt  =  CDbl  (GetPield  (Commandinf  oText-i  CMD_INP0_Y))  '*  from 

Commandinfo 

Call  DisplaySelectedPacility (f Xpt 1  fYpt) 

End  Select 

End  Sub 

Private  Sub  DisplaySelectedPaci lity  (ByVal  fXpt  As  Double*i  ByVal  fYpt  As 
Double) 

cProcName  =  ”DISPLAY_SELECTED_FACILITY" 

Dim  nHits  As  Long 
Dim  iRecNum  As  Long 
Dim  i  As  Long 

Dim  tMapHitsO  As  Inf oTool_Type 
Dim  tPacilitylnf 0  As  Pacility_Type 
Dim  rsGeoREPdata  As  Recordset 

'Get  number  of  "Hits”  using  the  MapBasic  function  -CSearchPoint ( ) > 

'FORMAT:  nHits  =  SearchPoint(  mapUinlDi  Xi  y  ) 

nHits  =  CLng(ob jGeoSelect.Eval("SGarchPoint("  S  iMapInf oblinID  &  "t"  &  fXpt  S 
&  fYpt  a  ")")) 

Set  rsGeoREPdata  =  dbAcropolis - OpenRecordset (Tbl^ValidateUniti  dbOpenTable-i 
dbReadOnly ) 

rsGeoREPdata . Index  =  "FACID" 

With  frmAriesMain 

! txtPropPacID . Clear 
! trvGISData -  Nodes  -  Clear 
iPropFacIDctr  =  D 

If  Not  (nHits  ==  D)  Then  'there  were  hits:  scan  using  "Searchinfo" 

ReDim  tMapHits ( nHits ) 
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For  i  =  1  To  nHits 

tflapHits  ( i )  -  HapTable  =  ob  jGeoSelect  - Eval  ("Searchinf  o  ("  8  i  &  8 

SEARCH_INFO_TABLE  8  ”)") 

iRecNum  =  CLng (ob jGeoSelect . Eval ("Searchlnf o (”  8  i  8  "t”  8 
SEARCH_INFO_ROlil  8  ”)")) 

ob jGeoSelect -Do  "Fetch  Rec  "  8  iRecNum  8  "  from  "  8 
triapHits(i)  -HapTable 

tMapHits(i) -GeoFacID  =  objGeoSelect-EvaKtllapHitsd) -HapTable  8 

"-coll") 


! txtPropFacID • Additem  tHapHits(i) -GeoFacID 
Next  i 

'Get  8  Display  Proposed  Facility  Data 
tFacilityInf 0  - FacID  =  ! txtPropFacID -List (D) 

Call  GetPropFacilityInfo (tFacilityInf Ot  rsGeoREFdata) 

Call  DisplayPropFacilitylnfo(tFacilitylnfo) 

Call  DisplayTreeViewInf 0 (tHapHits () n  nHits) 

If  (nHits  =  1)  Then 

IspinFacIDbtn-Visible  =  False 
Else 

! spinFacIDbtn - Visible  =  True 
End  If 

Else  'No  Facility  Selected  -  Clear  all  Proposed  Facility  fields 

IcboUIC-Clear 
ilstbxUnitName- Clear 

! IstbxUnitName - Additem  NO  FACILITY  SELECTED 
itxtCity  =  vbNullString 
ItxtState  =  vbNullString 
!txtZipCode  =  vbNullString 
End  If 
End  With 
End  Sub 

SetStatusText 

'  This  is  a  standard  method  that  Hapinfo  looks  for  in  its  Callback 

'  object-  If  Hapinfo  finds  this  method  in  the  Callback  objecti  it 

'  will  get  called  automatically  every  time  the  text  in  Hapinfo's 

'  status  bar  text  changes-  The  string  passed  in  is  a  tab-delimited 

'  string  containing  each  of  the  status  bar  "Fields"T  i-e-  -  the 

'  first  field  is  the  zoom-i  scalei  or  cursor  location!  the  second  field 

'  is  the  editable  layer-i  etc- 

Public  Sub  SetStatusText ( By Val  cStatusText  As  String) 
cProcName  =  "SET_STATUS_TEXT" 

Dim  cNewText  As  String 

cNewText  =  GetField ( cStatusTextn  vbTabn  1)  '*  get  first  field  in  tab- 

delimited  string 

If  Not  (cNewText  =  "")  Then 

frmAriesHain! AriesStatusBar-Panels(M) -Text  =  cNewText 
End  If 

End  Sub 
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THIS  PAGE  LEFT  INTENTIONALLY  BLANK 


Module  7.  MAPBASIC  PUBLIC  DECLARATIONS 


Purpose:  A  library  module  that  initializes  all  public  variables  and  constants  for 

communicating  with  the  integrated  mapping  component. 

Source  Type:  Visual  Basic  for  Applications 

Source  File:  libMAPBASIC.BAS 

Code  Listing: 


Attribute  VB_Name  =  ”libriAPBASIC" 


Maplnfo  version  M-D  -  System  defines 


This  file  contains  defines  useful  when  programming  in  the  flapBasic 
language.  There  are  three  versions  of“  this  file: 

MAPBASIC-DEF  -  dapBasic  syntax 
HAPBASIC . BAS  -  Visual  Basic  syntax 
riAPBASIC.H  -  C/C  +  +  syntax 


The  defines  in  this  file  are  organized  into  the  following  sections: 
General  Purpose  defines: 

dacrosi  Logical  constants!  Angle  conversion!  Colors 
ButtonPadInf 0  ( )  defines 
ColumnInfoO  defines 
Commandinf 0 C )  defines 
FileAttrO  defines 
IntersectNodes ( )  parameters 
LayerInfoC)  defines 
MapperlnfoO  defines 

denulteminf oBylDO  and  Menultemlnf oByHandler ( )  defines 

Ob jectGeography ( )  defines 

ObjectInfoO  defines 

SearchInfoO  defines 

Selectioninf o  ( )  defines 

Server  statement  and  function  defines 

StringCompare ( )  return  values 

StyleAttrC)  defines 

SystemInfoO  defines 

TableInfoO  defines 

WindowInfoO  defines 

Abbreviated  list  of  error  codes 

Backward  Compatibility  defines 


This  file  is  converted  into  MAPBASIC. H  by  doing  the  following: 

-  concatenate  MAPBASIC . DEF  and  MENU-DEF  into  MAPBASIC-H 
“  search  &  replace  at  begining  of  a  line  with  ”//" 

-  search  S;  replace  "Define”  at  begining  of  a  line  with  ”#define" 

-  delete  the  following  sections: 

*  General  Purpose  defines:  Macros!  Logical  Constants!  Angle 
Conversions 

*  Abbreviated  list  of  error  codes 

*  Backward  Compatibility  defines 

*  Menu  constants  whose  names  have  changed 
t  Obsolete  menu  items 

This  file  is  converted  into  MAPBASIC-BAS  by  doing  the  following: 

-  concatenate  MAPBASIC-DEF  and  MENU-DEF  into  MAPBASIC-BAS 

-  search  &  replace  "Define  <name>"  with  "Global  Const  <name>  =" 

e.g.  "<Define  ■CC!~z]+}  +{t!-zll>"  with  "Global  Const  \D  =  \1”  using  Brief 
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-  delete  the  following  sections: 

*  General  Purpose  defines:  flacrosi  Logical  Constants!  Angle 
Conversions 

*  Abbreviated  list  of  error  codes 

*  Backward  Compatibility  defines 

*  (lenu  constants  whose  names  have  changed 

*  Obsolete  menu  items 


General  Purpose  defines 


Colors 


Global  Const  BLACK  =  D 
Global  Const  WHITE  =  lb777B15 
Global  Const  RED  =  lb711bfiD 
Global  Const  GREEN  =  LSBfiD 
Global  Const  BLUE  =  SS5 
Global  Const  CYAN  =  LSS3S 
Global  Const  MAGENTA  =  lL7in3S 
Global  Const  YELLOW  =  lL77b^L0 


'  ButtonPadInf 0 ( )  defines 

Global  Const  BTNPAO^INFO^FLOATING  =  1 
Global  Const  BTNPAI)„INFO_UIDTH  =  2 
Global  Const  BTNPAI)_INFO_NBTNS  =  3 
Global  Const  BTNPAD„INFO_X  =  M 
Global  Const  BTNPAI)_INFO_Y  =  S 
Global  Const  BTNPA])_INFO JINIO  =  L 


'  ColumnInfoC)  defines 

Global  Const  COL^INFO^N AME  =  1 
Global  Const  C0L_INF0_NUM  =  2 
Global  Const  C0L_,INF0„TYPE  =  3 
Global  Const  COL^INFO.WIOTH  =  M 
Global  Const  COL_INFO_I>ECPLACES  =  5 
Global  Const  COL_INFO_INI>EXEI>  =  L 
Global  Const  COL_INFO__EI>ITABLE  =  7 


'  Column  type  defines!  returned  by  Columninf o (<col_ref>!  C0L__INF0_TYPE ) 


Global  Const  COL_TYPE_CHAR  =  1 
Global  Const  COL_TYPE_DECIMAL  =  2 

Global  Const  COL_TYPE_INTEGER  =  3 

Global  Const  COL_TYPE_SMALLINT  =  M 
Global  Const  COL_TYPE_DATE  =  S 
Global  Const  COL_TYPE__LOGICAL  =  L 

Global  Const  COL_TYPE_GR APHIC  =  7 

Global  Const  C0L_TYPE_FL0 AT  =  fi 


'  Commandinf 0  ( )  defines 


Global  Const  CMD^INFO^X  =  1 
Global  Const  CMD_INF0__Y  =  2 
Global  Const  CMD_INFO_SHIFT  =  3 
Global  Const  CnD_INFO_CTRL  =  M 
Global  Const  CMD_INF0_X5  =  S 
Global  Const  CMD_INFO_YB  =  L 
Global  Const  CMD_INF0_T00LBTN  =  7 
Global  Const  CMD^INFO^MENUITEM  =  B 
Global  Const  CMD^INFO.WIN  =  1 
Global  Const  CM3>_INF0_SELTYPE  =  1 
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Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 


Const  CnD_INF0_R0lJID  =  2 
Const  CriD_INFO__INTERRUPT  =  3 
Const  Cf1D_INF0_STATUS  =  1 
Const  CnD__INFOJSG  =  IDOD 
Const  CnD_INF0_DLG_0K  =  1 
Const  CnD„INFO_DLG_DBL  =  1 
Const  Cni>_INFO_FIND_RC  =  3 
Const  Cni>_INFO_FIND_ROIilID  =  M 
Const  CriD^INFO.XCnD  =  1 
Const  CI1I>_INF0__CUST0n_0BJ  =  1 
Const  CI1P_INF0_TASK_SUITCH  =  1 


'  Task  Switch-!  returned  by  Commandinf o (C[1D_INF0_TASK_SlilITCH) 


Global  Const  SWITCHING_OUT__OF_I1APINFO  =  D 
Global  Const  SbllTCHING^INTO^nAPINFO  =  1 


'  FileAttrO  defines 


Global  Const  FILE^ATTRJODE  =  1 
Global  Const  FILE_ATTR_FILESIZE  =  2 


'  File  Access  mod 


Global  Const  MODE 
Global  Const  MODE 
Global  Const  MODE 
Global  Const  MODE 
Global  Const  tIODE 


s-i  returned  by  Fi 


INPUT  =  D 
OUTPUT  =  1 
APPEND  =  2 
RANDOM  =  3 
.BINARY  ==  M 


eAttr  (<f  ile_id>  -i 


FILE_ATTR_I10DE) 


'  IntersectNodes ( ob jl 1  obj2i  mode)  parameters 

Global  Const  INCL^CROSSINGS  =  1 
Global  Const  INCL^COMMON  =  t 
Global  Const  INCL_ALL  =  7 


'  LayerInfoO  defines 

Global  Const  LAYER.INFO^NAME  =  1 

Global  Const  LAYER_INFO_EDITABLE  =  2 

Global  Const  LA YER_INFO_SELECTABLE  =  3 

Global  Const  LA YER_INF0_Z00n_LA YERED  =  M 

Global  Const  LA YER_INF0_Z00n_niN  =  5 

Global  Const  LA YER_INF0_Z00n_nAX  =  b 

Global  Const  LA YER^INFO^COSMETIC  =  7 

Global  Const  LA YER_,INFO_PATH  =  fi 

Global  Const  LA YER_INFO_DISPLAY  =  T 

Global  Const  LAYER_INFO_OVR..LINE  =  ID 

Global  Const  LAYER_INFO_OVR_PEN  =  11 

Global  Const  LAYER_INFO_OVR_BRUSH  =  12 

Global  Const  LAYER^INFO^OVR^SYIIBOL  =  13 
Global  Const  LAYER„INF0_0VR_F0NT  =  IM 

Global  Const  LAYER_INFO_LBL_EXPR  =  15 

Global  Const  LAYER_INFO„LBL_LT  =  lb 

Global  Const  LA YER_INFO_LBL_CURFONT  =  17 
Global  Const  LAYER_INFO_LBL_FONT  =  Ifi 

Global  Const  LAYER_INFO_LBL_P ARALLEL  =  IT 

Global  Const  LAYER_INFO_LBL_POS  =  2D 

Global  Const  LAYER_INFO_ARROUS  =  21 

Global  Const  LAYER_INFO_NODES  =  22 

Global  Const  LAYER_INFO_CENTROIDS  =  23 

Global  Const  LAYER_INFO_TYPE  =  2M 

Global  Const  LAYER_INFO_LBL_VISIBILITY  =  25 

Global  Const  LAYER_INF0_LBL_Z00n_l1IN  =  2b 

Global  Const  LA YER_INF0_LBL_Z00n_nAX  =  27 
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Global  Const  LAYER_INFO_LBL_AUTODISPLAY  =  E& 
Global  Const  LAYER__INFO_LBL_OVERLAP  =  BT 
Global  Const  LA YER_INFO_LBL_PUPLICATES  =  3D 
Global  Const  LAYER_INFO_LBL_OFFSET  =  31 
Global  Const  LA YER^INFO^LBL^flAX  =  3E 


'  Display  Modesi  returned  by  LayerInfoC)  for  LA YER_INFO_DISPLAY 


Global  Const  LA YER_INF0 JISPLAY_OFF  =  D 
Global  Const  LA YER_INFO_DISPLAY_GRAPHIC  =  1 
Global  Const  LAYER_INFO_DISPLAY_GLOBAL  =  2 
Global  Const  LAYER^INFOJISPL A Y_VALUE  =  3 


'  Label  Linetypesn  returned  by  LayerInfoO  for  LAYER_INFO_LBL_LT 


Global  Const  LA YER_INFO_LBL_LT_NONE  =  D 
Global  Const  LAYER_INFO_LBL_LT„SinPLE  =  1 
Global  Const  LAYER_INFO_^LBL_LT_ARROIil  =  2 


'  Label  Positions!  returned  by  LayerInfoO  for  LAYER_INFO_LBL_POS 


Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 


Const  LAYER_INFO_LBL_POS_CC 
Const  LAYER_INFO_LBL_POS_TL 
Const  LAYER_INFO_LBL_POS_TC 
Const  LAYER__INFO_LBL_,POS_TR 
Const  LAYER_INFO_LBL_POS_CL 
Const  LAYER_INFO_LBL_POS_CR 
Const  LAYER_INFO_LBL_POS_BL 
Const  LAYER__INFO_LBL_POS_BC 
Const  LAYER_INFO_LBL_POS__BR 


D 

1 

2 
3 

S 

L 

7 


'  Layer  Typesi  returned  by  LayerInfoC)  for  LAYER_INFO_TYPE 


Global  Const  LA YER_INFO_TYPE_NORnAL  =  D 
Global  Const  LA YER_INFO_TYPE_COSnETIC  =  1 
Global  Const  LAYER^INFO^TYPE^IHAGE  ==  2 
Global  Const  LAYER_INFO_^TYPE_THEnATIC  =  3 


'  Label  visibility  modesi  returned  by  LayerInfoO  for  LAYER_INFO_LBL_VISIBILITY 


Global  Const  LAYER_INFO_LBL_VIS_OFF  =  1 
Global  Const  LA YER__INFO_LBL_VIS_ZOOn  =  2 
Global  Const  LA YER_INFO_LBL_VIS_ON  =  3 


'  HapperlnfoO  defines 

Global  Const  nAPPER_INFO_ZOOI1  =  1 
Global  Const  I1APPER_INF0_SCALE  =  2 
Global  Const  nAPPER„INFO__CENTERX  =  3 
Global  Const  nAPPER_INFO_CENTERY  =  ^ 

Global  Const  nAPPER_INFO_niNX  =  5 
Global  Const  nAPPER_INFO_niNY  =  b 
Global  Const  tlAPPER^INFOJAXX  =  7 
Global  Const  flAPPER^INFOJAXY  =  & 

Global  Const  HAPPER^INFO^LAYERS  =  ■=! 

Global  Const  I1APPER_INF0.EDIT_LA YER  =  ID 
Global  Const  nAPPER_„INFO_XYUNITS  =  11 
Global  Const  MAPPER^INFOJISTUNITS  =  12 
Global  Const  I1APPER_INF0_AREAUNITS  =  13 
Global  Const  flAPPER^INFO^SCROLLBARS  =  IM 
Global  Const  nAPPER_INFO_DISPLAY  =  IS 
Global  Const  nAPPER_INFO_NUn_THEnATIC  =  lb 
Global  Const  P1APPER_INF0_C00RDSYS_CLAUSE  =  17 
Global  Const  nAPPER_INFO_COORDSYS_NAnE  =  IS 
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Display  Nodesi  returned  by  flapperInfoO  for  nAPPER_INFO__DISPLAY 


Global  Const  HAPPER^INFO JISPLA Y^SCALE  =  D 
Global  Const  nAPPER_INFO_DISPLA Y^ZOOfl  =  1 
Global  Const  f1APPER_INF0_DISPLAY_P0SITI0N  =  2 


'  flenulteminf oBylD ( )  and  Menultemlnf oByHandler ( )  defines 

Global  Const  riENUITEI1„INF0_ENABLED  =  1 

Global  Const  HENUITEn^INFO^CHECKED  =  E 

Global  Const  nENUITEn_INFO_CHECKABLE  =  3 
Global  Const  nENUITEn_INFO_SHOIi)HIDEABLE  =  M 
Global  Const  nENUITEH_INFO_ACCELERATOR  =  5 
Global  Const  nENUITEn_INFO_TEXT  =  k 
Global  Const  I1ENUITEn_INF0_HELPnSG  =  7 

Global  Const  nENUITEn_INFO JANDLER  =  6 

Global  Const  riENUITEn_INFO__ID  =  T 


'  Ob jectGeography ()  defines 


Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 


Const  0BJ_GE0_niNX  =  1 
Const  OBJ_GEO_.LINEBEGX  =  1 
Const  0BJ_GE0_P0INTX  =  1 
Const  0BJ_GE0_niNY  =  E 
Const  OBJ_GEO_LINEBEGY‘ =  E 
Const  0BJ_GE0__P0INTY  =  E 
Const  OBJ^GEOJAXX  =  3 
Const  OBJ_GEO_LINEENDX  =  3 
Const  0BJ_GE0_nAXY  =  H 
Const  OBJ_GEO_LINEENDY  =  M 
Const  OBJ_GEO_ARCBEGANGLE  =  5 
Const  OBJ_.GEO_TEXTLINEX  =  5 
Const  OBJ_GEO_ROUNDRADIUS  =  5 
Const  OBJ_GEO_ARCENDANGLE  =  b 
Const  OBJ_GEO_TEXTLINEY  =  b 
Const  OBJ_GEO_TEXTANGLE  =  7 


'  ObjectInfoO  defines 


Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 


Const  0BJ_INF0_TYPE  =  1 
Const  0BJ_INF0_PEN  =  E 
Const  OBJ_INFO_SYriBOL  =  E 
Const  0BJ_INF0__TEXTF0NT  =  E 
Const  0BJ_INF0_BRUSH  =  3 
Const  0BJ_INF0_NPNTS  =  ED 
Const  OBJ_INFO_TEXTSTRING  =  3 
Const  0BJ_INF0_Sn00TH  =  M 
Const  OBJ_INFO_FRAnEUIN  =  ^ 
Const  0BJ_INF0_NP0LYG0NS  =  El 
Const  OBJ_INFO_TEXTSPACING  =  M 
Const  OBJ_INFO_TEXTJUSTIFY  =  5 
Const  OBJ^INFO^FRAHETITLE  =  b 
Const  OBJ^INFO^TEXTARROU  =  b 


'  Object  types-!  returned  by  Ob  jectinf  o  (<ob  j>-»  OB  J_INFO_TYPE ) 


Global  Const  OBJ_TYPE_ARC  =  1 
Global  Const  OB J_TYPE_ELLIPSE  =  E 
Global  Const  OB J_TYPE_LINE  =  3 
Global  Const  OB J_TYPE_PLINE  =  M 
Global  Const  0Bd_TYPE_P0INT  =  S 
Global  Const  OB J^TYPE^FRAME  =  b 
Global  Const  OB J_TYPE„REGION  =  7 
Global  Const  OB J_TYPE_RECT  =  6 
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Global  Const  OB J_TYPE_ROUNDRECT  =  T 
Global  Const  OB J_TYPE_TEXT  =  ID 

'  SearchInfoO  defines 

Global  Const  SEARCH_INFO_TABLE  =  1 
Global  Const  SEARCH_INF0_R0W  =  5 


'  Selectioninf 0 ( )  defines 

Global  Const  SEL_INFO_TABLENAME  =  1 

Global  Const  SEL_INFO_SELNAnE  =  E 

Global  Const  SEL_INF0_NR0US  =  3 


Server  statement  and  function  defines 


Return  Codes 


Global  Const  SRV_SUCCESS  =  D 

Global  Const  SRV_SUCCESS_yiTH_INFO  =  1 

Global  Const  SRV_ERR0R  =  -1 

Global  Const  SRV_INVALI1)_HANI>LE  =  -S 

Global  Const  SRV_NEEI>_I>ATA  = 

Global  Const  SRV_NO_nORE_DATA  =  IDD 


'  Special  values  for  the  status  associated  with  a  fetched  value 


Global  Const  SRV_NULL_DATA  =  -1 
Global  Const  SRV_TRUNCATEI>_I>ATA  =  -E 


'  Server_ColumnInfo()  Attr  defines 


Global  Const  SRV_C0L_INF0_NA(1E  =  1 
Global  Const  SRV_COL_II\IFO_TYPE  =  E 
Global  Const  SRV_COL_INFO_UIDTH  =  3 
Global  Const  SRV_COL_INFO_PRECISION  =  H 
Global  Const  SRV_COL_INFO_SCALE  =  S 
Global  Const  SRV_COL_INFO_VALUE  =  b 
Global  Const  SRV_COL_INFO_STATUS  =  7 


'  Column  types-!  returned  by  Server_ColumnInfo(<stmt>i<colno>TSRV_COL_INFO_TYPE) 

I  _ _ _ _ _ _ _ _ — - - 


Global  Const  SRV_COL_TYPE_NONE  =  □ 

Global  Const  SRV_COL_TYPE_CHAR  =  1 
Global  Const  SRV_C0L_TYPE_I>ECII1AL  =  E 
Global  Const  SRV_COL_TYPE_INTEGER  =  3 
Global  Const  SRV_C0L_TYPE_SI1ALLINT  =  M 
Global  Const  SRV_COL_TYPE_I>ATE  =  S 
Global  Const  SRV_COL_TYPE_LOGICAL  =  b 
Global  Const  SRV_COL_TYPE_FLOAT  =  fl 
Global  Const  SRV_COL_TYPE_FIXEI>_LEN_STRING 
Global  Const  SRV_COL_TYPE_BIN_STRING  =  17 


lb 


'  Server_Dr i verinf o ( )  Attr  defines 


Global  Const  SRV_DRV_INFO_NAnE  =  1 
Global  Const  SR V_1>R V_INF0_N At1E_LIST  =  S 
Global  Const  SRV_]>RV_1>ATA_S0URCE  =  3 


'  Fetch  Directions  used  by  Server_Fetch ( ) 
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Global 

Global 

Global 

Global 


Const  SRV_FETCH_NEXT  =  -1 
Const  SR V_FETCH_PREV  =  -2 
Const  SRV_FETCH_FIRST  =  -3 
Const  SRV_FETCH_LAST  = 


'  StringCompare (<str_l>T  <str_S>)  return  values 

Global  Const  STR_LT  =  -1 
Global  Const  STR_GT  =  1 
Global  Const  STR_E(J  =  0 


'  StyleAttrO  defines 

Global  Const  PENJIDTH  =  1 
Global  Const  PEN_PATTERN  =  5 
Global  Const  PEN_C0L0R  =  M 
Global  Const  BRUSH_PATTERN  =  1 
Global  Const  BRUSH_F0REC0L0R  =  2 
Global  Const  BRUSH_BACKCOLOR  =  3 
Global  Const  F0NT_NAI1E  =  1 

Global  Const  FONT_STYLE  =  2 

Global  Const  F0NT_P0INTSIZE  =  3 

Global  Const  FONT_FORECOLOR  -  4 

Global  Const  F0NT_BACKC0L0R  =  5 

Global  Const  SYt1BOL_COI>E  =  1 

Global  Const  SYnBOL_COLOR  =  2 

Global  Const  SYt1B0L_P0INTSIZE  =  3 
Global  Const  SYI1B0L_ANGLE  =  4 
Global  Const  SYnBOL_FONT_NAnE  -  5 
Global  Const  SYnBOL_FONT_STYLE  =  b 
Global  Const  SYt1B0L_KIND  =  7 
Global  Const  SYI1B0L_CUST0n_NAI1E  =  6 
Global  Const  SYnBOL_CUSTOI1_STYLE  =  1 


— —  —  —  —  —  ^  —  - 

'  Symbol  kinds  returned  by  StyleAttr (<symbol> -i  SYflBOL^KIND) 

Global  Const  SYnBOL_KIND_VECTOR  =  1 
Global  Const  SYnBOL_KIND_FONT  =  2 
Global  Const  SYnBOL_KINI>_CUSTOI1  =  3 


'  SystemInfoO  defines 

Global  Const  SYS_INFO_PLATFORn  =  1 
Global  Const  SYS_INFO_APPVERSION  =  2 
Global  Const  SYS_INFO_niVERSION  =  3 
Global  Const  SYS_INFO_RUNTIHE  =  4 
Global  Const  SYS_INFO_CHARSET  =  5 
Global  Const  SYS_INFO_COPYPROTECTED  =  b 
Global  Const  SYS_INFO_APPLICATIONli)NI>  =  7, 
Global  Const  SYS_INF0_1>I>ESTATUS  =  6 

Global  Const  SYS_INFO_riAPINFOliINl>  =  T 

Global  Const  SYS_INFO_NUI1BER_FORnAT  =  10 

Global  Const  SYS_INF0_DATE_F0Rt1AT  =  11 

Global  Const  SYS_INF0_1>IG_INSTALLEI>  =  12 

Global  Const  SYS_INF0_I>IG_I10I>E  =  13 
Global  Const  SYS_INF0_niPLATF0RH  =  14 
Global  Const  SYS_INF0_M1>ICLIENTUN1>  =  15 


I-.-.-.-  —  —  -  —  —  --  —  — —  —  -  —  “  —  —  —  —  —  —  - 

*  Platfornii  returned  by  SysteniInfo(SYS_INF0_PLATF0Rt1) 

Global  Const  PLATFORn_SPECIAL  =  0 
Global  Const  PLATFORMJIN  =  1 

Global  Const  PLATF0Rn_l1AC  =  2 

Global  Const  PLATF0RI1_H0TIF  =  3 

Global  Const  PLATF0Rt1_Xll  =  4 
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Global  Const  PLATFORn_XOL  =  5 


*  Vfipsioni  poturnod  by  Sys  to  in  Info  (SYS _ INFO — fllPLATFORM) 

—  — —  —  —  -  —  —  “  —  —  - --- 

Global  Const  MIPLATFORO.SPECIAL  =  D 
Global  Const  MIPLATF0RI1_li)INlt  =  1 
Global  Const  niPLATF0Rn_UIN32  =  2 
Global  Const  riIPLATF0RI1_P0lilERnAC  =  3 
Global  Const  11IPLATF0RI1_nACbaK  =  M 
Global  Const  I1IPLATF0RI1_HP  =  S 
Global  Const  niPLATF0RI1_SUN  =  b 


'  TableInfoO  defines 

Global  Const  TAB_INF0_NA(1E  =  1 
Global  Const  TAB_INF0_NUI1  =  2 
Global  Const  TAB_INFO_TYPE  =  3 
Global  Const  TAB_INF0_NC0LS  =  M 
Global  Const  TAB_INF0_f1APPABLE  =  S 
Global  Const  TAB_INFO_READONLY  =  b 
Global  Const  TAB_INF0_TEi1P  =  7 
Global  Const  TAB_INFO_NROliIS  =  fl 
Global  Const  TAB_INFO_EDITED  =  T 
Global  Const  TAB_INFO_FASTEI>IT  =  10 
Global  Const  TAB_INF0_UND0  =  11 
Global  Const  TAB_INFO_HAPPABLE_TABLE  =  12 
Global  Const  TAB_INFO_USERnAP  =  13 

Global  Const  TAB_INFO_USERBROUSE  =  IM 

Global  Const  TAB_INFO_USERCLOSE  =  15 
Global  Const  TAB_INFO_USEREI>ITABLE  =  lb 
Global  Const  TAB_INF0_USERREI10VEI1AP  =  17 
Global  Const  TAB_INFO_USERDISPLAYnAP  =  18 
Global  Const  TAB_INFO_TABFILE  =  IT 

Global  Const  TAB_INFO_riINX  =  20 

Global  Const  TAB_INFO_niNY  =  21 

Global  Const  TAB_INF0_I1AXX  =  22 

Global  Const  TAB_INF0_I1AXY  =  23 

Global  Const  TAB_INFO_SEAriLESS  =  2*4 

Global  Const  TAB_INF0_C00RI>SYS_I1INX  =  25 

Global  Const  TAB_INFO_COORDSYS_mNY  =  2b 

Global  Const  TAB_INF0_C00RDSYS_t1AX.X  =  27 

Global  Const  TAB_INF0_C00RDSYS_I1AXY  =  28 

Global  Const  TAB_INFO_COORDSYS_CLAUSE  =  21 

Global  Const  TAB_INFO_COORI>SYS_NAnE  =  30 

Global  Const  TAB_INF0_NREFS  =  31 


'  Table  type  definesn  returned  by  TableInfo(<tab_ref>i  TAB_INFO_TYPE) 
r  _ _ 

Global  Const  TAB_TYPE_BASE  =  1 
Global  Const  TAB_TYPE_RESULT  =  B 
Global  Const  TAB_TYPE„VIEIJ  =  3 
Global  Const  TAB_TYPE_If1AGE  =  M 
Global  Const  TAB_TYPE_LINKED  =  5 


'  UindowInfoO  defines 

Global  Const  li)IN_INf O.NAME  =  1 
Global  Const  li]IN_INF0„TYPE  =  3 
Global  Const  lilIN_INFO JIDTH  =  H 
Global  Const  liJIN_INFO_HEIGHT  =  5 
Global  Const  liIIN_INF0_X  =  t 
Global  Const  IJIN_INF0_Y  =  7 
Global  Const  liJIN_INF0_T0Pn0ST  =  6 
Global  Const .  UIN__INFO__STATE  =  T 
Global  Const  UIN_INF0_TABLE  =  10 
Global  Const  lilIN_INF0_LEGENI>S_t1AP  =  ID 
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Global  Const  liJIN^INFO^OPEN  =  11 
Global  Const  (ilIN_INF0 JND  =  IE 
Global  Const  WIN^INFOJINDOlilID  =  13 
Global  Const  UIN.INFO WORKSPACE  =  m 
Global  Const  li)IN__INF0_CL0NEUIN])0U  =  IS 
Global  Const  bllN^INFO^SYSMENUCLOSE  =  IL 
Global  Const  li)IN_INF0_AUT0SCR0LL  =  17 


'  Window  typesT  returned  by  Uindowinf  o  (<win_id> i  lijIN__INFO_TYPE) 


Global  Const  UINJAPPER  =  1 
Global  Const  UIN^BROlilSER  =  S 
Global  Const  b)IN_LAYOUT  =  3 
Global  Const  UIN^GRAPH  =  M 
Global  Const  blIN_„BUTTONPAI)  =  IT 
Global  Const  UINJELP  =  IDDl 
Global  Const  WINJAPBASIC  =  IDDE 
Global  Const  liIIN_nESSAGE  =  1003 
Global  Const  bilN^RULER  =  1007 
Global  Const  liIIN^INFO  =  lOOfl 
Global  Const  UIN^LEGEND  =  lOOT 
Global  Const  WIN_STATISTICS  =  1010 
Global  Const  bJIN^MAPINFO  =  1011 


'  Version  E  window  types  no  longer  used  in  version  3  or  version  M 


Global  Const  UIN_T00LPICKER  =  IDOM 
Global  Const  WIN_PENPICKER  =  IDDS 
Global  Const  UIN.SYMBOLPICKER  =  lOOt 


'  Window  statesi  returned  by  Windowinf o (<win_id>i  WIN_INFO_STATE ) 


Global  Const  WIN_STATE_NORnAL  =  0 
Global  Const  WIN^STATE^MINIMIZEI)  =  1 
Global  Const  WIN^STATEJAXIMIZED  =  E 


'  Set  Next  Document  Style  defines 

f  s  =  s  =  =.=  =  =:  =  =  =  =  =  =  =  =  =  =  s  =  =  =  =  =  =:  =  =  =  =  sss;  =  =  =  =  =  =  =  =  =  =  = 

Global  Const  UIN_STYLE_STANDARD  =  0 
Global  Const  WIN_STYLE_CHILD  =  1 
Global  Const  WIN_STYLE_POPUP_FULLCAPTION  =  E 
Global  Const  WIN_STYLE_POPUP  =  3 


end  of  nAPBASIC.DEF 


Mapinfo  version  M-D  -  Menu  Item  Definitions 


This  file  contains  defines  useful  when  programming  in  the  flapBasic 
language.  The  definitions  in  this  file  describe  the  standard  Hapinfo 
functionality  available  via  the  ”Run  Menu  Command”  HapBasic  statement. 


The  defines  in  this  file  are  organized  to  match  the  sequence  of 
declarations  in  the  HAPINFOW - HNU  filei  which  in  turn  reflects  the 
organization  of  the  flaplnfo  menus  and  buttonpads- 


File  &  Send  Nail  menus 


Global  Const  n_FILE_NEW  =  IDl 
Global  Const  n_FILE_0PEN  =  IDE 
Global  Const  n_FILE_0PEN_0DBC  =  lit 
Global  Const  n_FILE_ADD_W0RKSPACE  =  106 
Global  Const  n_FILE_CL0SE  =  1D3 
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Global  Const  n_FILE__CLOSE_ALL  =  lOM 
Global  Const  I1_FILE_SAVE  =  IDS 
Global  Const  n„FILE_SAVE_COP Y__AS  =  lOb 
Global  Const  n_FILE_SA VE_lilORKSPACE  =  IDT 
Global  Const  n_FILE_SA VE JINDObJ^AS  =  bDT 
Global  Const  n_FILE_REVERT  =  ID? 

Global  Const  n_FILE__RUN  =  IID 
Global  Const  n_^FILE_PAGE_SETUP  =  111 
Global  Const  M^FILE^PRINT  =  HE 
Global  Const  I1_FILE_EXIT  =  113 

Global  Const  n_SENDnAIL_CURRENTblINDOU  =  IIM 
Global  Const  H  SENDMAIL ^WORKSPACE  =  IIS 


'  Edit  menu 


Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 


Const  n^EDIT 
Const  n^EDIT. 
Const  n^EDIT 
Const  I1_EDIT. 
Const  n_EDIT 
Const  n_EDIT_ 
Const  n_EDIT_ 
Const  n_EDIT_ 
Const  n_EPIT_ 


UNDO  =  EDI 
CUT  =  EDE 
COPY  =  ED3 
PASTE  =  EDM 
CLEAR  =  EDS 
CLEAROBJ  =  EDb 
RESHAPE  =  ILDl 
NEU_„R0U  =  7DE 
GETINFO  =  ED? 


'  Objects  menu 


Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 


Const 

Const 

Const 

Const 

Const 

Const 

Const 

Const 

Const 

Const 

Const 

Const 


n^OBJECTS 

n_0BJECTS. 

n^OBJECTS^ 

n^OBJECTS 

n^OBJECTS^ 

n_0BJECTS_ 

n_0BJECTS_ 

n_0BJECTS_ 

n_0BJECTS_ 

n^OBJECTS^ 

n^OBJECTS. 

n  OBJECTS 


SET_.TARGET  =  IblD 
CLEAR_TARGET  =  ILll 
COMBINE  =  ILDS 
SPLIT  =  ILIE 
ERASE  =  1L13 
ERASE^OUT  =  ILIM 
OVERLAY  =  ILIS 
BUFFER  =  ILOL 
SMOOTH  =  IbDE 
UNSMOOTH  =  lbD3 
CVTJGON  =  1LD7 
CVT  PLINE  =  ILDM 


uery  menu 


Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 
Global  Const 


M_ANALYZE_SELECT  =  3D1 
M_ANALYZE_S(2LflUERY  =  3DS 
M_ANALYZE_SELECTALL  =*=  3D3 
M_ANALYZEJNSELECT  =  3DM 
M_ANALYZE_FIND  =  3D5 
M_ANALYZE_FIND_SELECTION  =  30b 
M  ANALYZE_CALC__STATISTICS  =  3DT 


'  Tablei  MaintenanceT  and  Raster  menus 


Global  Const  M_TABLE_UPDATE_COLUMN  =  MDS 
Global  Const  M_TABLE_APPEND  =  Mil 
Global  Const  M_TABLE_GE0C0DE  =  MD? 

Global  Const  M__TABLE_CREATE_POINTS  =  MDB 
Global  Const  M_TABLE__MERGE_USING_COLUMN  =  MDb 
Global  Const  M_TABLE_IMP0RT  =  MDl 
Global  Const  M  TABLE^EXPORT  =  MDE 


Global  Const  M_TABLE_MODIFY_STRUCTURE  =  MDM 

Global  Const  M_TABLE_DELETE  =  MDT 

Global  Const  M^TABLE^RENAME  =  MID 

Global  Const  M_TABLE_PACK  =  M03 

Global  Const  M  TABLE_MAKEMAPPABLE  =  M15 


Global  Const  I1_TABLE_UNLINK  =  mb 
Global  Const  n_TABLE_REFRESH  =  Ml? 

Global  Const  n_TABLE_RASTER_STYLE  =  MIM 
Global  Const  n_TABLE_RASTER_REG  =  MIB 
Global  Const  I1_T00LS_RASTER_REG  =  1730 


'  Options  menu 


Global  Const  tl.FORMAT.PICK.LINE  =  SOI 
Global  Const  n_FORnAT_PICK_FILL  =  SOS 
Global  Const  n_F0RI1AT_PICK_SYI1B0L  =  SD3 
Global  Const  t1_F0Rt1AT_PICK_F0NT  =  SOM 
Global  Const  n_lJIN]>0lil_BUTT0NPA])  =  bOS 
Global  Const  f1_lilIND01J_LEGEND  =  bOb 
Global  Const  n_UINI>01il_STATISTICS  =  bO? 

Global  Const  n_UINDOIil_nAPBASIC  =  bOfl 
Global  Const  n_MINI>OU_STATUSBAR  =  bib 
Global  Const  n_F0RnAT_CUST0n_C0L0RS  =  bl7 
Global  Const  n_EI>IT_PREFERENCES  =  208 
Global  Const  n_EDIT_PREFERENCES_SYSTEn  =  210 
Global  Const  I1_E])IT_PREFERENCES_FILE  =  211 
Global  Const  n_EDIT_PREFERENCES_nAP  =  212 
Global  Const  t1_EDIT_PREFERENCES_COONTRY  =  213 
Global  Const  n_EI>IT_PREFERENCES_PATH  =  2m 


'  lilindow  menu 


Global  Const  n_UIND0U_BR0USE  =  bOl 
Global  Const  n_UINDOlU_nAP  =  b02 
Global  Const  n_UIN]>01J_GRAPH  =  b03 
Global  Const  n_UIND01il_LAY0UT  =  bOM 
Global  Const  l1_lilINI>0li)_REI>ISTRICT  =  blS 
Global  Const  n_UINI>0U_REI>RA0  =  blD 
Global  Const  n_UINDOU_TILE  =  bll 
Global  Const  M_lilINDOIi)_CASCAl>E  =  bl2 
Global  Const  n_IJINDOU_ARRANGEICONS  =  bl3 
Global  Const  M_UIND0U_I10RE  =  blM 
Global  Const  I1_lilIND0U_FIRST  =  b2D 


'  Note!  the  End  through  60th  windows  can  be  accessed  as  (l1_lilIND0U_FIRST+i-l) 


'  Help  menu 


Global  Const  n_HELP_CONTENTS  =  1202 
Global  Const  I1_HELP_SEARCH  =  1203 
Global  Const  I1_HELP_USE_HELP  =  lEOM 
Global  Const  n_HELP_TECHSUPP0RT  =  1206 
Global  Const  n_HELP_C0NNECT_niF0RUn  =  lEOT 
Global  Const  n_HELP_ABOUT  =  1205 

Global  Const  M_HELP_CONTEXTSENSITIVE  =  1201 
Global  Const  M_HELP_HELPnODE  =  lEOb 


'  Browse  menu 


Global  Const  I1_BR0USE_PICK_FIEL1)S  =  70H 
Global  Const  n_BR01i)SE_0PTI0NS  =  703 


'  Nap  menu 


Global  Const  t1_nAP_LAYER_C0NTR0L  =  601 
Global  Const  I1_nAP_THEnATIC  =  307 
Global  Const  n_l1AP_n01)IFY_THEHATIC  =  306 
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Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 

Global 


Const  l1_nAP_CHAN6E_VIEU  =  6DS 
Const  l1_nAP_CL0NE_nAPPER  =  611 
Const  I1_I1AP_PREVI0US  =  aOt 
Const  n_l1AP_ENTIRE_LAYER  =  607 
Const  n_nAP_CLEAR_CUST0I1_LABELS  =  614 
Const  I1_I1AP_SAVE_C0SI1ETIC  =  BOT 
Const  n_l1AP_CLEAR_C0SnETIC  =  610 
Const  l1_nAP_SET_CLIP_REGI0N  =  613 
Const  n_nAP_CLIP_REGI0N_0N0FF  =  613 
Const  I1_t1AP_SETUPDIGITIZER  =  603 
Const  n_nAP_0PTI0NS  =  60S 


'  Layout  menu 


Global  Const  n_LAYOUT_CHANGE_VIEU  =  IDS 
Global  Const  I1_LAY0UT_ACTUAL  =  103 
Global  Const  n_LAYOUT_ENTIRE  =  104 
Global  Const  n_LAY0UT_PREVI0US  =  105 
Global  Const  I1_LAY0UT_BRINGSFR0NT  =  IDb 
Global  Const  n_LAY0UT_SEN])SBACIC  =  107 
Global  Const  11_LAY0UT_ALIGN  =  106 
Global  Const  t1_LAYOUT_I>ROPSHAI)OUS  =  101 
Global  Const  n_LAY0UT_DISPLAY0PTI0NS  =  101 


'  Graph  menu 


Global  Const  n_GRAPH_TYPE  =  1001 
Global  Const  n_GRAPH_LABEL_AXIS  =  lOOS 
Global  Const  t1_GRAPH_VALUE_AXIS  =  1003 
Global  Const  n_GRAPH_SERIES  =  1004 


'  MapBasic  menu 


Global  Const  n_nAPBASIC_CLEAR  =  1101 
Global  Const  I1_I1APBASIC_SAVEC0NTENTS  =  llOS 


'  Redistrict  menu 


Global  Const  I1_RE]>ISTRICT_ASSIGN  =  705 
Global  Const  I1_REI>ISTRICT_TARGET  =  70t 
Global  Const  n_REI>ISTRICT_Al)D  =  707 
Global  Const  n_REl>ISTRICT_I>ELETE  =  706 
Global  Const  t1_REI>ISTRlCT_0PTI0NS  =  701 


'  Main  Buttonpad 


Global  Const  n_T00LS_SELECT0R  =  1701 
Global  Const  n_T0OLS_SEARCH_RECT  =  17ES 
Global  Const  n_T00LS_SEARCH_R ADIUS  =  1703 
Global  Const  I1_T00LS_SEARCH_B0UN])ARY  =  1704 
Global  Const  ri_T00LS_EXPAND  =  1705 
Global  Const  H_T00LS_SHRINK  =  170b 
Global  Const  M_T00LS_RECENTER  =  170S 
Global  Const  I1_TOOLS_PNT_(3UERY  =  1707 
Global  Const  f1_T00LS_LABELER  =  1706 
Global  Const  l1_TOOLS_DRAGyiNI>Olil  =  1734 
Global  Const  n_T00LS_RULER  =  1710 


'  Drawing  Buttonpad 


Global  Const  I1_T00LS_P0INT  =  1711 
Global  Const  ,t1_T00LS_LINE  =  1713 
Global  Const  n_T00LS_P0LYLINE  =  1713 
Global  Const  ri_T00LS_ARC  =  171b 
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Global  Const  I1_T00LS_P0LYG0N  =  17m 
Global  Const  n__T00LS_ELLIPSE  =  1715 
Global  Const  n_TOOLS_RECTANGLE  =  1717 
Global  Const  n_T00LS_R0UNDEDRECT  =  171fl 
Global  Const  M^TOOLS^TEXT  =  17DT 
Global  Const  n_T00LS_FRAnE  =  17n 
Global  Const  n_TOOLS_ADD_NODE  =  1733 


'  Menu  and  ButtonPad  items  that  do  not  appear  in  the  standard  menus 


Global  Const  M^TOOLSJAPBASIC  =  17ED 
Global  Const  I1_T00LS_SEARCH_P0LYG0N  =  1733 


'  end  of  riENU-DEF 
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Module  8.  SPATIAL  SELECTION  PROGRAM 


Purpose:  A  MapBasic  program  that  spatially  selects  the  desired  data  within  50  miles  of  the 

specified  location  and  locates  the  closest  Army  Reserve  support  facilities. 

Source  Type:  MapBasic  Spatial  Application  Development  Language 

Source  File:  ARIESARCH.MBA 

Code  Listing: 


'  ARIES  SDSS  SPATIAL  SELECTION  PROGRAM  —  PHASE  One 

r 

'  EXTRACTS  SELECTED  DATA  FROM  AROUND  PROPOSED  FACILITY  SITE 

r 

f  Hi* 

Include  "c : \mapinf o\mapbasic\mapbasic . def ” 

Include  "c:\mapinfo\mapbasic\menu-def" 

Include  ”c: \map inf o\mapbasic\i cons -def" 

Declare  Sub  Main 

Global  AMSA_ID.AMSA_Dist-, 

ECS_ID-.  ECS_Dist-. 

RZA^IDi  RZA_Dist*. 

f ProposedFacil ity if AreaDistancei  fAreaFacIDi  f AreaZipCode i 
f AreaGlfl*! f ArealRR if AreaflMA nTargetZip  1  cPropFacID  As  String 

Sub  MAIN 

Dim  FacIDLati  FacIDLong  As  Float 

Dim  ob jAreaBuf f er lOb jDistanceBuf f er “I  objGlflBuffer  As  Object 
Dim  iRouNum  As  Integer 

Dim  cFilePathi  AuthStrength  As  String 


cFilePath  =  Appl icationDirectory^ ( ) 

Set  Map  Center  (-TL*i37)  Zoom  3SD0  Units  "mi” 


Create  Index 
Create  Index 
Create  Index 
Create  Index 


On  US_Zips (Zip_Code) 
on  AMSA (Fac_Zip) 
on  ECS(Fac_Zip) 
on  RZA(Zip) 


Create  Index 
Create  Index 
Create  Index 
Create  Index 
Create  Index 


on  GE0REF(Fac„ID) 
on  GlfiClilE(Zip) 
on  IRR(Zipc) 
on  (3MA(Zip) 
on  Non_Clos (Zip) 


f AreaDistance  =  cFilePath  &  "AriesDataXAreaDist • DBF" 
fAreaFacID  =  cFilePath  &  "AriesDataXAreaFac - DBF" 
fAreaZipCode  =  cFilePath  Z  "AriesDataXAreaZip - DBF" 
f ProposedFacility  =  cFilePath  Z  "AriesDataXPropFac . DBF" 

fAreaGlfl  =  cFilePath  Z  "Ar iesDataXAreaGlfi . DBF" 
fArealRR  =  cFilePath  &  "Ar iesDataXArealRR • DBF" 
fArea(3MA  =  cFilePath  &  "Ar  iesDataXAreaiSMA  -  DBF" 

Open  Table  f AreaDistance 
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DeletG  From  AreaDist 


Open  Table  fAreaFacIO 
Delete  From  AreaFac 

Open  Table  f AreaZipCode 
Delete  From  AreaZip 

Open  Table  f ProposedFaci 1 ity 
cPropFacID  =  PropFac • Fac_ID 
Pack  Table  PropFac  Data 
Close  Table  PropFac 

Open  Table  FAreaGlfl 
Delete  From  AreaGlfi 

Open  Table  fArealRR 
Delete  From  ArealRR 

Open  Table  fAreatSMA 
Delete  From  AreaflnA 


(1)  DETERHINE  LATITUDE  &  LONGITUDE  OF  TARGET  ZIP  CODE 
(E)  CENTER  MAP  AT  TARGET  ZIP 

(3)  CREATE  SOfll  RADIUS  CIRCLE  AROUND  TARGET  ZIP  CODE. 


Find  Using  GEOREF ( Fac_ID ) 

Find  cPropFacID 

FacIDLat  =  Commandinf o ( CnD_INF0_X ) 

FacIDLong  =  Commandinf  o  ( CnD__INF0_Y) 

Set  CoordSys  Earth 

'Create  Point (FacIDLat i  FacIDLong)  Symbol  (STt  REDt  EM) 

Insert  Into  Sites  (obj)  Values  (CreatePoint (FacIDLati  FacIDLong)) 
Update  Sites  Set  Fac_ID  =  cPropFacID  Where  RowID  =  1 

Set  (lap  Center  ( FacIDLat t FacIDLong )  Zoom  SDQ  Units  ”mi” 

Set  Distance  Units  "mi” 

ob jAreaBuf f er  =  CreateCircle (FacIDLat iFacIDLong tSD ) 
ob jGlflBuf f er  =  CreateCircle (FacIDLatTFacIDLongiSD) 
ob jDistanceBuf f er  =  CreateCircle (FacIDLat nFacIDLong t3DD) 


BUILD  A  TABLE  OF  ZIPCODES  U/IN  SO  MI  OF  THE  PROPOSED 
FACILITY 


Select  Zip_Code  From  US_Zips 

Where  Obj  Within  ob jAreaBuf fer  order  by  Zip_Code  into  TempZip 

Insert  Into  AreaZip 
Select  *  From  TempZip 

Commit  Table  AreaZip 
Pack  Table  AreaZip  Data 


BUILD  A  TABLE  OF  FACILITY  ID'S  W/IN  SD  MI  OF  THE  PROPOSED 
FACILITY 


Select  Fac__ID  From  GEOREF 

Where  Obj  Within  ob jAreaBuf fer  order  by  Fac_ID  into  TempFacID 
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Insert  Into  AreaFac 

Select  *  From  TempFacID 

Commit  Table  AreaFac 
Pack  Table  AreaFac  Data 


DETERniNE  DISTANCE  TO  NEAREST  RECRUIT  STATION 


Select  *  From  RZA . 

Where  Obj  Within  ob jDistanceBuf f er  into  TempRZA 

Select  Distance ( Centro idX (obj ) t Centro id Y (obj) TFacIDLatiFacIDLong i^mi”) 
"Distance” 

From  TempRZA  order  by  Distance  into  TempRZA_Dist 
RZA_Dist  =  TempRZA_Dist-Distance 


'  DETERMINE  DISTANCE  TO  NEAREST  AMSA  LOCATION 


Select  *  From  AMSA 

Where  Obj  Within  ob jDistanceBuf fer  into  TempAMSA 

Select  Distance  (Centro idX  (obj)  i Centro idY  (obj)  TFacIDLatiFacIDLong-i^mi") 
"Distance" 

From  TempAMSA  order  by  Distance  into  TempAMSA_Dist 
AMSA_Dist  =  TempAMSA_Dist • Distance 


DETERMINE  DISTANCE  TO  NEAREST  EflUIPMENT  SITE 


Select  t  From  ECS 

Where  Obj  Within  ob jDistanceBuf fer  into  TempECS 

Select  Distance ( Cent roidX( obj )TCentroidY (obj )TFacIDLatTFacIDLongn"mi") 
"Distance" 

From  TempECS  order  by  Distance  into  TempECS__Dist 
ECS__Dist  =  TempECS_Dist. Distance 


'  DETERMINE  AUTHORIZED  STRENGTH  OF  THE  NAT  GUARD  UNITS 

'  WITHIN  5D  MILES  OF  TARGET  ZIP  CODE 

Select  *  From  N0N_CL0S 

Where  Obj  Within  ob jAreaBuf f er  into  TempNGUnits 

Select  SUM(AUTH)"NO_AUTH_NG" 

From  TempNGUnits  into  Strength 

AuthStrength  =  Strength . N0_AUTH_NG 


OUTPUT  AMSAn  ECS-,  RZA  DISTANCES  TO  AREA  DISTANCE  FILE 


Insert  into  AreaDist 

Values  UMSA_Dist-.  ECS_Dist-.  RZA^Dist-,  AuthStrength) 
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Commit  Table  AreaDist 
Pack  Table  AreaDist  Data 


»  BUILD  A  TABLE  OF  Glfi  Personnel  U/IN  5D  MI  OF  THE  PROPOSED 

'  FACILITY 

Select  UIC-.  LEFT$(ZIP.S)  "ZIPCODE"-,  PRI  "HOS”  From  GIBCUE 
Where  Obj  Within  objClflBuffer  and  PRI  <> 

Order  by  UICt  ZIP  into  TempGlfl 

Insert  Into  AreaG16 
Select  ^  From  TempGlfl 

Commit  Table  AreaGlfi 
Pack  Table  AreaGlfi  Data 


'  BUILD  A  TABLE  OF  IRR  Personnel  W/IN  SO  MI  OF  THE  PROPOSED 

'  FACILITY 

Select  ZIPC  ”ZIP"-»  LEFT$ (PnOS-,3)  "tlOS”  From  IRR 

Where  Obj  Within  ob jAreaBuf f er  and  ZIPC  <>  ""  and  PMOS  <> 

Order  by  Zipc  into  TempIRR 

Insert  Into  ArealRR 
Select  *  From  TempIRR 

Commit  Table  ArealRR 
Pack  Table  ArealRR  Data 


BUILD  A  TABLE  OF  (2riA  Personnel  W/IN  50  MI  OF  THE  PROPOSED 
FACILITY 


Select  LEFT$(ZIP-.5)  "ZIPCODE"-.  nWCATlE-.  I1WCAT3A-,  MBCATIB-,  MBCATBA-. 

flHCATlB-.  nHCAT3A  From  flflA 
Where  Obj  Within  ob jAreaBuf fer 
Order  by  Zip  into  TempflflA 

Insert  Into  Area(2HA 
Select  *  From  Temp(3nA 

Commit  Table  Areat2riA 
Pack  Table  AreaflflA  Data 


'  END  MAIN  PROGRAM 

Delete  from  Sites 
Commit  Table  Sites 
Pack  Table  Sites  Data 

Exit  Sub 

end  SUB 
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